[aerogear-dev] Publish new release of digger-java client

[Wei Li]

Hi AeroGear community,

We have been using the digger-java client module in our product for the last couple of months. At this point I think the API is stable enough and I think we should release them.

However, because at some point during the 1.0.0-SNAPSHOT version, we have introduced some broken changes (and our product is released using the version before the broken changes are made), we now need to do 2 releases;

1. Release 1.0.1 from this branch: https://github.com/wei-lee/digger-java/tree/fix-for-3-18-release. This is before the broken change is introduced.

2. From master (1.0.2).

Apologies in advance for the manually version change. Matthias does point it out that it is not the right way to do it.

So, can we publish those releases? Sorry for the problem we have caused, I promise it won't be like this the next time....

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

[Matthias Wessendorf]

On Wed, Aug 2, 2017 at 12:45 PM, Wei Li <[hidden email]> wrote:

Hi AeroGear community,

We have been using the digger-java client module in our product for the last couple of months. At this point I think the API is stable enough and I think we should release them.

However, because at some point during the 1.0.0-SNAPSHOT version, we have introduced some broken changes (and our product is released using the version before the broken changes are made), we now need to do 2 releases;

1. Release 1.0.1 from this branch: https://github.com/wei-lee/digger-java/tree/fix-for-3-18-release. This is before the broken change is introduced.

we can release this, let's make a branch, with a more reasonable name, available on upstream

 

2. From master (1.0.2).

ok

So, why do we need an old release? Not sure I really get that. 

 

Apologies in advance for the manually version change. Matthias does point it out that it is not the right way to do it.

So, can we publish those releases? Sorry for the problem we have caused, I promise it won't be like this the next time....

there are no big problems. I'd suggest we simply continue to follow a normal java release process, as discussed here and avoid manual bumps.

Also, it never hurts to release bits to the community very often (release early, release often). This likely avoids issues like the above 

-M 

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

[Matthias Wessendorf]

Related, are we OK to release org.jboss.aerogear::jenkins-client in version 0.3.8 - to maven central ? 

On Wed, Aug 2, 2017 at 12:57 PM, Matthias Wessendorf <[hidden email]> wrote:

On Wed, Aug 2, 2017 at 12:45 PM, Wei Li <[hidden email]> wrote:

Hi AeroGear community,

We have been using the digger-java client module in our product for the last couple of months. At this point I think the API is stable enough and I think we should release them.

However, because at some point during the 1.0.0-SNAPSHOT version, we have introduced some broken changes (and our product is released using the version before the broken changes are made), we now need to do 2 releases;

1. Release 1.0.1 from this branch: https://github.com/wei-lee/digger-java/tree/fix-for-3-18-release. This is before the broken change is introduced.

we can release this, let's make a branch, with a more reasonable name, available on upstream

 

2. From master (1.0.2).

ok

So, why do we need an old release? Not sure I really get that. 

 

Apologies in advance for the manually version change. Matthias does point it out that it is not the right way to do it.

So, can we publish those releases? Sorry for the problem we have caused, I promise it won't be like this the next time....

there are no big problems. I'd suggest we simply continue to follow a normal java release process, as discussed here and avoid manual bumps.

Also, it never hurts to release bits to the community very often (release early, release often). This likely avoids issues like the above 

-M 

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

[Matthias Wessendorf]

On Wed, Aug 2, 2017 at 12:57 PM, Matthias Wessendorf <[hidden email]> wrote:

On Wed, Aug 2, 2017 at 12:45 PM, Wei Li <[hidden email]> wrote:

Hi AeroGear community,

We have been using the digger-java client module in our product for the last couple of months. At this point I think the API is stable enough and I think we should release them.

However, because at some point during the 1.0.0-SNAPSHOT version, we have introduced some broken changes (and our product is released using the version before the broken changes are made), we now need to do 2 releases;

1. Release 1.0.1 from this branch: https://github.com/wei-lee/digger-java/tree/fix-for-3-18-release. This is before the broken change is introduced.

we can release this, let's make a branch, with a more reasonable name, available on upstream

 

2. From master (1.0.2).

ok

So, why do we need an old release? Not sure I really get that. 

 

Apologies in advance for the manually version change. Matthias does point it out that it is not the right way to do it.

So, can we publish those releases? Sorry for the problem we have caused, I promise it won't be like this the next time....

there are no big problems. I'd suggest we simply continue to follow a normal java release process, as discussed here and avoid manual bumps.

here is the link:

https://github.com/aerogear/collateral/wiki/Release-Process-(Java)

 

Also, it never hurts to release bits to the community very often (release early, release often). This likely avoids issues like the above 

-M 

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

[Wei Li]

Yes, I was just going to ask the same questions. If we can publish it, it will be great.

On Wed, Aug 2, 2017 at 11:59 AM, Matthias Wessendorf <[hidden email]> wrote:

Related, are we OK to release org.jboss.aerogear::jenkins-client in version 0.3.8 - to maven central ? 

On Wed, Aug 2, 2017 at 12:57 PM, Matthias Wessendorf <[hidden email]> wrote:

On Wed, Aug 2, 2017 at 12:45 PM, Wei Li <[hidden email]> wrote:

Hi AeroGear community,

We have been using the digger-java client module in our product for the last couple of months. At this point I think the API is stable enough and I think we should release them.

However, because at some point during the 1.0.0-SNAPSHOT version, we have introduced some broken changes (and our product is released using the version before the broken changes are made), we now need to do 2 releases;

1. Release 1.0.1 from this branch: https://github.com/wei-lee/digger-java/tree/fix-for-3-18-release. This is before the broken change is introduced.

we can release this, let's make a branch, with a more reasonable name, available on upstream

 

2. From master (1.0.2).

ok

So, why do we need an old release? Not sure I really get that. 

 

Apologies in advance for the manually version change. Matthias does point it out that it is not the right way to do it.

So, can we publish those releases? Sorry for the problem we have caused, I promise it won't be like this the next time....

there are no big problems. I'd suggest we simply continue to follow a normal java release process, as discussed here and avoid manual bumps.

Also, it never hurts to release bits to the community very often (release early, release often). This likely avoids issues like the above 

-M 

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

[Wei Li]

I have create the release-1.0.1 branch: https://github.com/aerogear/digger-java/tree/release-1.0.1. We can do the release from there.

On Wed, Aug 2, 2017 at 11:57 AM, Matthias Wessendorf <[hidden email]> wrote:

On Wed, Aug 2, 2017 at 12:45 PM, Wei Li <[hidden email]> wrote:

Hi AeroGear community,

We have been using the digger-java client module in our product for the last couple of months. At this point I think the API is stable enough and I think we should release them.

However, because at some point during the 1.0.0-SNAPSHOT version, we have introduced some broken changes (and our product is released using the version before the broken changes are made), we now need to do 2 releases;

1. Release 1.0.1 from this branch: https://github.com/wei-lee/digger-java/tree/fix-for-3-18-release. This is before the broken change is introduced.

we can release this, let's make a branch, with a more reasonable name, available on upstream

 

2. From master (1.0.2).

ok

So, why do we need an old release? Not sure I really get that. 

The problem is that 1.0.2 is not backward compatible with 1.0.1. We have a release branch that needs to built with 1.0.1, but master needs to be built with 1.0.2.

 

 

Apologies in advance for the manually version change. Matthias does point it out that it is not the right way to do it.

So, can we publish those releases? Sorry for the problem we have caused, I promise it won't be like this the next time....

there are no big problems. I'd suggest we simply continue to follow a normal java release process, as discussed here and avoid manual bumps.

Also, it never hurts to release bits to the community very often (release early, release often). This likely avoids issues like the above 

-M 

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

[Wei Li]

@Matthias are you ok to publish both releases, and release jenkins-java-client as well? Anything else I can help with?

On Wed, Aug 2, 2017 at 12:18 PM, Wei Li <[hidden email]> wrote:

I have create the release-1.0.1 branch: https://github.com/aerogear/digger-java/tree/release-1.0.1. We can do the release from there.

On Wed, Aug 2, 2017 at 11:57 AM, Matthias Wessendorf <[hidden email]> wrote:

On Wed, Aug 2, 2017 at 12:45 PM, Wei Li <[hidden email]> wrote:

Hi AeroGear community,

We have been using the digger-java client module in our product for the last couple of months. At this point I think the API is stable enough and I think we should release them.

However, because at some point during the 1.0.0-SNAPSHOT version, we have introduced some broken changes (and our product is released using the version before the broken changes are made), we now need to do 2 releases;

1. Release 1.0.1 from this branch: https://github.com/wei-lee/digger-java/tree/fix-for-3-18-release. This is before the broken change is introduced.

we can release this, let's make a branch, with a more reasonable name, available on upstream

 

2. From master (1.0.2).

ok

So, why do we need an old release? Not sure I really get that. 

The problem is that 1.0.2 is not backward compatible with 1.0.1. We have a release branch that needs to built with 1.0.1, but master needs to be built with 1.0.2.

 

 

Apologies in advance for the manually version change. Matthias does point it out that it is not the right way to do it.

So, can we publish those releases? Sorry for the problem we have caused, I promise it won't be like this the next time....

there are no big problems. I'd suggest we simply continue to follow a normal java release process, as discussed here and avoid manual bumps.

Also, it never hurts to release bits to the community very often (release early, release often). This likely avoids issues like the above 

-M 

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

[Matthias Wessendorf]

On Wed, Aug 2, 2017 at 1:18 PM, Wei Li <[hidden email]> wrote:

I have create the release-1.0.1 branch: https://github.com/aerogear/digger-java/tree/release-1.0.1. We can do the release from there.

On Wed, Aug 2, 2017 at 11:57 AM, Matthias Wessendorf <[hidden email]> wrote:

On Wed, Aug 2, 2017 at 12:45 PM, Wei Li <[hidden email]> wrote:

Hi AeroGear community,

We have been using the digger-java client module in our product for the last couple of months. At this point I think the API is stable enough and I think we should release them.

However, because at some point during the 1.0.0-SNAPSHOT version, we have introduced some broken changes (and our product is released using the version before the broken changes are made), we now need to do 2 releases;

1. Release 1.0.1 from this branch: https://github.com/wei-lee/digger-java/tree/fix-for-3-18-release. This is before the broken change is introduced.

we can release this, let's make a branch, with a more reasonable name, available on upstream

 

2. From master (1.0.2).

ok

So, why do we need an old release? Not sure I really get that. 

The problem is that 1.0.2 is not backward compatible with 1.0.1. We have a release branch that needs to built with 1.0.1, but master needs to be built with 1.0.2.

to follow semVer, let's name it 1.1.0 - instead of 1.0.2 since it's not backwards compatible

 

 

 

Apologies in advance for the manually version change. Matthias does point it out that it is not the right way to do it.

So, can we publish those releases? Sorry for the problem we have caused, I promise it won't be like this the next time....

there are no big problems. I'd suggest we simply continue to follow a normal java release process, as discussed here and avoid manual bumps.

Also, it never hurts to release bits to the community very often (release early, release often). This likely avoids issues like the above 

-M 

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

[Karel Piwko]

Hello All,

should not the version bump be minor/major to indicated backwards compatibility changes according to semver? Also by releasing 1.0.2 you remove the path to (eventually) patch 1.0.1 in the future and release as 1.0.2. Releasing it as 1.0.3 would add even more confusion imho.

Thanks,

Karel

On Wed, Aug 2, 2017 at 1:18 PM, Wei Li <[hidden email]> wrote:

I have create the release-1.0.1 branch: https://github.com/aerogear/digger-java/tree/release-1.0.1. We can do the release from there.

On Wed, Aug 2, 2017 at 11:57 AM, Matthias Wessendorf <[hidden email]> wrote:

On Wed, Aug 2, 2017 at 12:45 PM, Wei Li <[hidden email]> wrote:

Hi AeroGear community,

We have been using the digger-java client module in our product for the last couple of months. At this point I think the API is stable enough and I think we should release them.

However, because at some point during the 1.0.0-SNAPSHOT version, we have introduced some broken changes (and our product is released using the version before the broken changes are made), we now need to do 2 releases;

1. Release 1.0.1 from this branch: https://github.com/wei-lee/digger-java/tree/fix-for-3-18-release. This is before the broken change is introduced.

we can release this, let's make a branch, with a more reasonable name, available on upstream

 

2. From master (1.0.2).

ok

So, why do we need an old release? Not sure I really get that. 

The problem is that 1.0.2 is not backward compatible with 1.0.1. We have a release branch that needs to built with 1.0.1, but master needs to be built with 1.0.2.

 

 

Apologies in advance for the manually version change. Matthias does point it out that it is not the right way to do it.

So, can we publish those releases? Sorry for the problem we have caused, I promise it won't be like this the next time....

there are no big problems. I'd suggest we simply continue to follow a normal java release process, as discussed here and avoid manual bumps.

Also, it never hurts to release bits to the community very often (release early, release often). This likely avoids issues like the above 

-M 

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

[Karel Piwko]

On Wed, Aug 2, 2017 at 1:33 PM, Matthias Wessendorf <[hidden email]> wrote:

On Wed, Aug 2, 2017 at 1:18 PM, Wei Li <[hidden email]> wrote:

I have create the release-1.0.1 branch: https://github.com/aerogear/digger-java/tree/release-1.0.1. We can do the release from there.

On Wed, Aug 2, 2017 at 11:57 AM, Matthias Wessendorf <[hidden email]> wrote:

On Wed, Aug 2, 2017 at 12:45 PM, Wei Li <[hidden email]> wrote:

Hi AeroGear community,

We have been using the digger-java client module in our product for the last couple of months. At this point I think the API is stable enough and I think we should release them.

However, because at some point during the 1.0.0-SNAPSHOT version, we have introduced some broken changes (and our product is released using the version before the broken changes are made), we now need to do 2 releases;

1. Release 1.0.1 from this branch: https://github.com/wei-lee/digger-java/tree/fix-for-3-18-release. This is before the broken change is introduced.

we can release this, let's make a branch, with a more reasonable name, available on upstream

 

2. From master (1.0.2).

ok

So, why do we need an old release? Not sure I really get that. 

The problem is that 1.0.2 is not backward compatible with 1.0.1. We have a release branch that needs to built with 1.0.1, but master needs to be built with 1.0.2.

to follow semVer, let's name it 1.1.0 - instead of 1.0.2 since it's not backwards compatible

+1, exactly my point :-) 

 

 

 

Apologies in advance for the manually version change. Matthias does point it out that it is not the right way to do it.

So, can we publish those releases? Sorry for the problem we have caused, I promise it won't be like this the next time....

there are no big problems. I'd suggest we simply continue to follow a normal java release process, as discussed here and avoid manual bumps.

Also, it never hurts to release bits to the community very often (release early, release often). This likely avoids issues like the above 

-M 

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

[Wei Li]

Sure, let's do that.

On Wed, Aug 2, 2017 at 12:35 PM, Karel Piwko <[hidden email]> wrote:

On Wed, Aug 2, 2017 at 1:33 PM, Matthias Wessendorf <[hidden email]> wrote:

On Wed, Aug 2, 2017 at 1:18 PM, Wei Li <[hidden email]> wrote:

I have create the release-1.0.1 branch: https://github.com/aerogear/digger-java/tree/release-1.0.1. We can do the release from there.

On Wed, Aug 2, 2017 at 11:57 AM, Matthias Wessendorf <[hidden email]> wrote:

On Wed, Aug 2, 2017 at 12:45 PM, Wei Li <[hidden email]> wrote:

Hi AeroGear community,

We have been using the digger-java client module in our product for the last couple of months. At this point I think the API is stable enough and I think we should release them.

However, because at some point during the 1.0.0-SNAPSHOT version, we have introduced some broken changes (and our product is released using the version before the broken changes are made), we now need to do 2 releases;

1. Release 1.0.1 from this branch: https://github.com/wei-lee/digger-java/tree/fix-for-3-18-release. This is before the broken change is introduced.

we can release this, let's make a branch, with a more reasonable name, available on upstream

 

2. From master (1.0.2).

ok

So, why do we need an old release? Not sure I really get that. 

The problem is that 1.0.2 is not backward compatible with 1.0.1. We have a release branch that needs to built with 1.0.1, but master needs to be built with 1.0.2.

to follow semVer, let's name it 1.1.0 - instead of 1.0.2 since it's not backwards compatible

+1, exactly my point :-) 

 

 

 

Apologies in advance for the manually version change. Matthias does point it out that it is not the right way to do it.

So, can we publish those releases? Sorry for the problem we have caused, I promise it won't be like this the next time....

there are no big problems. I'd suggest we simply continue to follow a normal java release process, as discussed here and avoid manual bumps.

Also, it never hurts to release bits to the community very often (release early, release often). This likely avoids issues like the above 

-M 

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

[Matthias Wessendorf]

Hello,

I've pushed 1.1.0 (master) and 1.0.1 JARs over to maven central

They should be online tomorrow .... 

On Wed, Aug 2, 2017 at 1:38 PM, Wei Li <[hidden email]> wrote:

Sure, let's do that.

On Wed, Aug 2, 2017 at 12:35 PM, Karel Piwko <[hidden email]> wrote:

On Wed, Aug 2, 2017 at 1:33 PM, Matthias Wessendorf <[hidden email]> wrote:

On Wed, Aug 2, 2017 at 1:18 PM, Wei Li <[hidden email]> wrote:

I have create the release-1.0.1 branch: https://github.com/aerogear/digger-java/tree/release-1.0.1. We can do the release from there.

On Wed, Aug 2, 2017 at 11:57 AM, Matthias Wessendorf <[hidden email]> wrote:

On Wed, Aug 2, 2017 at 12:45 PM, Wei Li <[hidden email]> wrote:

Hi AeroGear community,

We have been using the digger-java client module in our product for the last couple of months. At this point I think the API is stable enough and I think we should release them.

However, because at some point during the 1.0.0-SNAPSHOT version, we have introduced some broken changes (and our product is released using the version before the broken changes are made), we now need to do 2 releases;

1. Release 1.0.1 from this branch: https://github.com/wei-lee/digger-java/tree/fix-for-3-18-release. This is before the broken change is introduced.

we can release this, let's make a branch, with a more reasonable name, available on upstream

 

2. From master (1.0.2).

ok

So, why do we need an old release? Not sure I really get that. 

The problem is that 1.0.2 is not backward compatible with 1.0.1. We have a release branch that needs to built with 1.0.1, but master needs to be built with 1.0.2.

to follow semVer, let's name it 1.1.0 - instead of 1.0.2 since it's not backwards compatible

+1, exactly my point :-) 

 

 

 

Apologies in advance for the manually version change. Matthias does point it out that it is not the right way to do it.

So, can we publish those releases? Sorry for the problem we have caused, I promise it won't be like this the next time....

there are no big problems. I'd suggest we simply continue to follow a normal java release process, as discussed here and avoid manual bumps.

Also, it never hurts to release bits to the community very often (release early, release often). This likely avoids issues like the above 

-M 

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

[Wei Li]

Great. Thanks Matthias.

On Thu, Aug 3, 2017 at 9:13 AM, Matthias Wessendorf <[hidden email]> wrote:

Hello,

I've pushed 1.1.0 (master) and 1.0.1 JARs over to maven central

They should be online tomorrow .... 

On Wed, Aug 2, 2017 at 1:38 PM, Wei Li <[hidden email]> wrote:

Sure, let's do that.

On Wed, Aug 2, 2017 at 12:35 PM, Karel Piwko <[hidden email]> wrote:

On Wed, Aug 2, 2017 at 1:33 PM, Matthias Wessendorf <[hidden email]> wrote:

On Wed, Aug 2, 2017 at 1:18 PM, Wei Li <[hidden email]> wrote:

I have create the release-1.0.1 branch: https://github.com/aerogear/digger-java/tree/release-1.0.1. We can do the release from there.

On Wed, Aug 2, 2017 at 11:57 AM, Matthias Wessendorf <[hidden email]> wrote:

On Wed, Aug 2, 2017 at 12:45 PM, Wei Li <[hidden email]> wrote:

Hi AeroGear community,

We have been using the digger-java client module in our product for the last couple of months. At this point I think the API is stable enough and I think we should release them.

However, because at some point during the 1.0.0-SNAPSHOT version, we have introduced some broken changes (and our product is released using the version before the broken changes are made), we now need to do 2 releases;

1. Release 1.0.1 from this branch: https://github.com/wei-lee/digger-java/tree/fix-for-3-18-release. This is before the broken change is introduced.

we can release this, let's make a branch, with a more reasonable name, available on upstream

 

2. From master (1.0.2).

ok

So, why do we need an old release? Not sure I really get that. 

The problem is that 1.0.2 is not backward compatible with 1.0.1. We have a release branch that needs to built with 1.0.1, but master needs to be built with 1.0.2.

to follow semVer, let's name it 1.1.0 - instead of 1.0.2 since it's not backwards compatible

+1, exactly my point :-) 

 

 

 

Apologies in advance for the manually version change. Matthias does point it out that it is not the right way to do it.

So, can we publish those releases? Sorry for the problem we have caused, I promise it won't be like this the next time....

there are no big problems. I'd suggest we simply continue to follow a normal java release process, as discussed here and avoid manual bumps.

Also, it never hurts to release bits to the community very often (release early, release often). This likely avoids issues like the above 

-M 

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

[Matthias Wessendorf]

published:   http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22org.jboss.aerogear%22%20AND%20a%3A%22digger-java-client%22   

On Thu, Aug 3, 2017 at 10:27 AM, Wei Li <[hidden email]> wrote:

Great. Thanks Matthias.

On Thu, Aug 3, 2017 at 9:13 AM, Matthias Wessendorf <[hidden email]> wrote:

Hello,

I've pushed 1.1.0 (master) and 1.0.1 JARs over to maven central

They should be online tomorrow .... 

On Wed, Aug 2, 2017 at 1:38 PM, Wei Li <[hidden email]> wrote:

Sure, let's do that.

On Wed, Aug 2, 2017 at 12:35 PM, Karel Piwko <[hidden email]> wrote:

On Wed, Aug 2, 2017 at 1:33 PM, Matthias Wessendorf <[hidden email]> wrote:

On Wed, Aug 2, 2017 at 1:18 PM, Wei Li <[hidden email]> wrote:

I have create the release-1.0.1 branch: https://github.com/aerogear/digger-java/tree/release-1.0.1. We can do the release from there.

On Wed, Aug 2, 2017 at 11:57 AM, Matthias Wessendorf <[hidden email]> wrote:

On Wed, Aug 2, 2017 at 12:45 PM, Wei Li <[hidden email]> wrote:

Hi AeroGear community,

We have been using the digger-java client module in our product for the last couple of months. At this point I think the API is stable enough and I think we should release them.

However, because at some point during the 1.0.0-SNAPSHOT version, we have introduced some broken changes (and our product is released using the version before the broken changes are made), we now need to do 2 releases;

1. Release 1.0.1 from this branch: https://github.com/wei-lee/digger-java/tree/fix-for-3-18-release. This is before the broken change is introduced.

we can release this, let's make a branch, with a more reasonable name, available on upstream

 

2. From master (1.0.2).

ok

So, why do we need an old release? Not sure I really get that. 

The problem is that 1.0.2 is not backward compatible with 1.0.1. We have a release branch that needs to built with 1.0.1, but master needs to be built with 1.0.2.

to follow semVer, let's name it 1.1.0 - instead of 1.0.2 since it's not backwards compatible

+1, exactly my point :-) 

 

 

 

Apologies in advance for the manually version change. Matthias does point it out that it is not the right way to do it.

So, can we publish those releases? Sorry for the problem we have caused, I promise it won't be like this the next time....

there are no big problems. I'd suggest we simply continue to follow a normal java release process, as discussed here and avoid manual bumps.

Also, it never hurts to release bits to the community very often (release early, release often). This likely avoids issues like the above 

-M 

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev