Using the new approach the bundle and release versions are 'marketing versions'. So it doesn't matter - except if we know users are doing Require-Bundle, then moving to 1.5 would be preferable. Actually, I think 1.5 would be the best number in the Blueprint case because there isn't a major restructuring going on - which I think is your point :-)
Jeremy On 13 July 2015 at 14:40, Daniel Kulp <[email protected]> wrote: > > Well, there is also the issue of selecting the “version” to use. For > example, for this blueprint release, we have numbers like 1.3.1 and 1.1.1 and > 1.4.4. Do we just up everything in blueprint to something like 1.5? Or do > we bite the bullet and just say that since we are flipping version schemes, > start at 2.0? (obviously, just talking about the bundle version, not the > package versions) > > JPA was a bit easer since the entire tree was going to a 2.0. It was a good > time to do it. > > Dan > > > >> On Jul 13, 2015, at 9:24 AM, Jeremy Hughes <[email protected]> wrote: >> >> It would also seem, that we are going to have top level modules doing >> either one of the release processes for some time. >> >> I think it would be best, if we can get to a single release process - >> but that may take some time. I think there are two things we should >> vote on to make this concrete: >> >> a) each top-level-module MUST use either the old 'release by bundle' >> approach OR the new 'release by top-level-module' approach. >> b) we favour projects moving the 'release by top-level-module' approach >> >> i.e. saying what we prefer as a community, without putting the onus on >> a release manager to do the conversion the next time a release is >> needed. >> >> I'll leave this thread going for a while for more discussion before >> opening a vote thread. >> >> Thanks, >> Jeremy >> >> On 13 July 2015 at 14:05, Jeremy Hughes <[email protected]> wrote: >>> Ok, that sounds fair. Subsystem is another one. Would you have a >>> chance to document how you approached converting the JPA module (ok so >>> I know you reimplemented at the same time :-) ... so that others can >>> use the same approach for other modules? >>> >>> Jeremy >>> >>> On 13 July 2015 at 14:04, Christian Schneider <[email protected]> >>> wrote: >>>> Hi Jeremy, >>>> >>>> yes it was the intent. It is quite some work to convert a submodule to the >>>> new release process though. So I think the best approach is to convert each >>>> module >>>> at a certain point and do submodule releases from then on. >>>> As long as a submodule is not converted I propose we continue doing >>>> releases >>>> in the per bundle style. So we have a smooth transition and do not hold off >>>> releases. >>>> >>>> Christian >>>> >>>> >>>> On 13.07.2015 14:37, Jeremy Hughes wrote: >>>>> >>>>> Hi, >>>>> >>>>> We had a discussion at the end of May about changing out release >>>>> process to release at the top level module only. I've just realised >>>>> this release vote was for sub-modules and that really we should have >>>>> done a full Blueprint release. >>>>> >>>>> Christian, that was the intent wasn't it? >>>>> >>>>> I guess next time :-) >>>>> >>>>> Cheers, >>>>> Jeremy >>>>> >>>>> On 2 July 2015 at 21:46, Sergey Beryozkin <[email protected]> wrote: >>>>>> >>>>>> This vote passes with 4 binding +1s. >>>>>> >>>>>> I'll promote the artifacts >>>>>> Thanks all >>>>>> Sergey >>>>>> >>>>>> On 29/06/15 16:56, Sergey Beryozkin wrote: >>>>>>> >>>>>>> Hi All >>>>>>> >>>>>>> This is a vote to support the release of blueprint-parser-1.3.1, >>>>>>> blueprint-noosgi-1.1.1, blueprint-web 1.1.1. >>>>>>> >>>>>>> The staging repository for blueprint-parser-1.3.1 is at >>>>>>> >>>>>>> https://repository.apache.org/content/repositories/orgapachearies-1027 >>>>>>> >>>>>>> The staging repository for blueprint-noosgi-1.1.1 and >>>>>>> blueprint-web-1.1.1 is at >>>>>>> >>>>>>> https://repository.apache.org/content/repositories/orgapachearies-1028 >>>>>>> >>>>>>> The following issues have been addressed: >>>>>>> >>>>>>> https://issues.apache.org/jira/browse/ARIES-1322 >>>>>>> https://issues.apache.org/jira/browse/ARIES-1323 >>>>>>> https://issues.apache.org/jira/browse/ARIES-1334 >>>>>>> >>>>>>> A servlet-based deployment of Blueprint contexts with custom namespace >>>>>>> handlers will work better in non OSGI environments after the release. >>>>>>> >>>>>>> The vote is open for the next 72 hours, here is my +1, >>>>>>> >>>>>>> Thanks, Sergey >>>>>>> >>>> >>>> >>>> -- >>>> Christian Schneider >>>> http://www.liquid-reality.de >>>> >>>> Open Source Architect >>>> http://www.talend.com >>>> > > -- > Daniel Kulp > [email protected] - http://dankulp.com/blog > Talend Community Coder - http://coders.talend.com >
