Sure, let's do that.

On Wed, Aug 2, 2017 at 12:35 PM, Karel Piwko <kpiwko@redhat.com> wrote:

On Wed, Aug 2, 2017 at 1:33 PM, Matthias Wessendorf <matzew@apache.org> wrote:

On Wed, Aug 2, 2017 at 1:18 PM, Wei Li <weil@redhat.com> 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 <matzew@apache.org> wrote:

On Wed, Aug 2, 2017 at 12:45 PM, Wei Li <weil@redhat.com> 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 

--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

weil@redhat.com    M: +353862393272    

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
twitter: http://twitter.com/mwessendorf

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

weil@redhat.com    M: +353862393272    

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
twitter: http://twitter.com/mwessendorf

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

KAREL PIWKO

MANAGER, MOBILE QE

Red Hat Czech Republic

Purkyňova 647/111 

612 00 Brno, Czech Republic

kpiwko@redhat.com    IM: kpiwko

TRIED. TESTED. TRUSTED.

@redhatway   @redhatinc   @redhatsnaps

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

--

WEI LI

SENIOR SOFTWARE ENGINEER

Red Hat Mobile

weil@redhat.com    M: +353862393272    

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev