On Wed, Aug 22, 2018 at 10:27 AM, Romain Manni-Bucau <[email protected]> wrote:
> snapshot -> release process is mainly about dropping SNAPSHOT since mvn > release plugin will upgrade after the release the version to prepare it for > next release. > Alright, just wanted to make sure :) > for specs we tend to only use major.minor but recently we started using > the standard major.minor.patch, i dont have a strong opinion here. > I don't think we need that in this case. I think a minor bump is warranted in all cases. - Ray > > Romain Manni-Bucau > @rmannibucau <https://twitter.com/rmannibucau> | Blog > <https://rmannibucau.metawerx.net/> | Old Blog > <http://rmannibucau.wordpress.com> | Github > <https://github.com/rmannibucau> | LinkedIn > <https://www.linkedin.com/in/rmannibucau> | Book > <https://www.packtpub.com/application-development/java-ee-8-high-performance> > > > Le mer. 22 août 2018 à 16:17, Raymond Auge <[email protected]> a > écrit : > >> Ah gee Romain, I hope I have not mislead you with the versions I provided. >> >> The versions I provided (1.1-SNAPSHOT) are the version in the current >> poms. Does that not mean we should be releasing with the next increment >> (i.e. 1.2)? >> >> I'm not familiar with the versioning approach of Geronimo yet. Other >> Apache projects increment with a even/odd for release/dev. So should I >> release things as the SAME version currently in the poms, or with the next >> increment? >> >> - Ray >> >> On Wed, Aug 22, 2018 at 10:04 AM, Romain Manni-Bucau < >> [email protected]> wrote: >> >>> Created the versions on jira, hope i didnt forget one but if so just let >>> me know >>> >>> Romain Manni-Bucau >>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>> <https://rmannibucau.metawerx.net/> | Old Blog >>> <http://rmannibucau.wordpress.com> | Github >>> <https://github.com/rmannibucau> | LinkedIn >>> <https://www.linkedin.com/in/rmannibucau> | Book >>> <https://www.packtpub.com/application-development/java-ee-8-high-performance> >>> >>> >>> Le mer. 22 août 2018 à 15:56, Raymond Auge <[email protected]> a >>> écrit : >>> >>>> Hello, can I get a PMC to make versions for the items listed earlier in >>>> this thread? >>>> >>>> Also, since there were no versions the JIRA issues did not get proper >>>> triage. I can only do this for the few issues I created so if a PMC >>>> wouldn't mind also doing this so that we have a proper changelog it would >>>> be great. >>>> >>>> Sincerely, >>>> - Ray >>>> >>>> On Tue, Aug 21, 2018 at 12:23 PM, Romain Manni-Bucau < >>>> [email protected]> wrote: >>>> >>>>> For the MP spec impl we do <spec name marker>_<version> like >>>>> JwtAuth_1.0 for instance, we can surely do the same: >>>>> >>>>> Interceptor1.2_1.1 >>>>> El2.2_1.1 >>>>> etc... >>>>> >>>>> side note: el (as servlet, websocket) has a tomcat version so we might >>>>> want to merge both @asf long term >>>>> >>>>> If you didnt get your versions tomorrow and nobody complains, ping >>>>> back here, i'll move forward and create it (off now so not that easy) >>>>> >>>>> Romain Manni-Bucau >>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>>>> <https://rmannibucau.metawerx.net/> | Old Blog >>>>> <http://rmannibucau.wordpress.com> | Github >>>>> <https://github.com/rmannibucau> | LinkedIn >>>>> <https://www.linkedin.com/in/rmannibucau> | Book >>>>> <https://www.packtpub.com/application-development/java-ee-8-high-performance> >>>>> >>>>> >>>>> Le mar. 21 août 2018 à 16:47, Raymond Auge <[email protected]> >>>>> a écrit : >>>>> >>>>>> I see your point. >>>>>> >>>>>> Would you rather each spec have a version to release against? I'm ok >>>>>> with it, and I am confident I can still to a single release from N tags >>>>>> ;) >>>>>> >>>>>> However, I have to ask a PMC to make JIRA versions for all of these: >>>>>> >>>>>> Spec / current artifact version >>>>>> ================================ >>>>>> interceptor 1.2 / 1.1-SNAPSHOT >>>>>> el 2.2 / 1.1-SNAPSHOT >>>>>> atinject 1.0 / 1.1-SNAPSHOT >>>>>> annotation 1.3 / 1.1-SNAPSHOT >>>>>> cdi 2.0 / 1.1-SNAPSHOT >>>>>> jaxrs 2.1 / 1.1-SNAPSHOT >>>>>> jbatch 1.0 / 1.1-SNAPSHOT >>>>>> validation 2.0 / 1.0-SNAPSHOT >>>>>> json 1.1 / 1.1-SNAPSHOT >>>>>> jsonb 1.0 / 1.1-SNAPSHOT >>>>>> >>>>>> I only thought of a single JIRA version so a PMC's time would not be >>>>>> so wasted making all those ;) >>>>>> >>>>>> What shall we do? >>>>>> - Ray >>>>>> >>>>>> On Tue, Aug 21, 2018 at 10:36 AM, Romain Manni-Bucau < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi Raymond, >>>>>>> >>>>>>> Not sure I have in mind the exact content of your work but if we can >>>>>>> have N changelog and just see the single vote as an aggregate it works. >>>>>>> The point is to ensure users can report against something clear the >>>>>>> issues and MP is not clear since it is actually a lot of specs and the >>>>>>> same >>>>>>> spec version will be in N version of MP specs. >>>>>>> >>>>>>> Does it make sense? >>>>>>> >>>>>>> Romain Manni-Bucau >>>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>>>>>> <https://rmannibucau.metawerx.net/> | Old Blog >>>>>>> <http://rmannibucau.wordpress.com> | Github >>>>>>> <https://github.com/rmannibucau> | LinkedIn >>>>>>> <https://www.linkedin.com/in/rmannibucau> | Book >>>>>>> <https://www.packtpub.com/application-development/java-ee-8-high-performance> >>>>>>> >>>>>>> >>>>>>> Le mar. 21 août 2018 à 16:00, Raymond Auge <[email protected]> >>>>>>> a écrit : >>>>>>> >>>>>>>> Hey all, >>>>>>>> >>>>>>>> I've been working with a number of specs related to and >>>>>>>> complementary to Microprofile. >>>>>>>> >>>>>>>> I would like to release these as a single release vote to save >>>>>>>> process. >>>>>>>> >>>>>>>> What I was not sure about was under what version in JIRA should I >>>>>>>> place the related changes so that I can create a single changelog. >>>>>>>> >>>>>>>> Does it sound appropriate to maybe create a mp-2.0 version I could >>>>>>>> use? >>>>>>>> >>>>>>>> Sincerely, >>>>>>>> -- >>>>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>>>>>>> (@rotty3000) >>>>>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> >>>>>>>> (@Liferay) >>>>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> >>>>>>>> (@OSGiAlliance) >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>>>>> (@rotty3000) >>>>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> >>>>>> (@Liferay) >>>>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> >>>>>> (@OSGiAlliance) >>>>>> >>>>> >>>> >>>> >>>> -- >>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>>> (@rotty3000) >>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> >>>> (@Liferay) >>>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> >>>> (@OSGiAlliance) >>>> >>> >> >> >> -- >> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >> (@rotty3000) >> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> >> (@Liferay) >> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> >> (@OSGiAlliance) >> > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay) Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance)
