Oh, I forgot, it's this issue I was talking of :) https://issues.apache.org/jira/browse/KARAF-2118
2013/1/16 Achim Nierbeck <[email protected]> > I'm fine with 2.3.1 since it's what we initially have planed, but tbh I'd > rather have a minor version upgrade than keep about 10 to 12 patch versions > where features have been introduced. > Just for example somehow the fix for 3.0.0 where the roles have been > corrected did get into the 2.2.10 version also. This results into > incompatibilities with other software, at this point our new WebConsole > doesn't work anymore. This shouldn't have happened, it's been a > API-breaking change. Instead of keeping 10 patch versions where we also > have "minor" improvements we really should think about increasing the minor > version more often. > > just my 2 cents here. > > Regards, Achim > > > 2013/1/16 Jamie G. <[email protected]> > > Making a 2.4.x branch immediately after 2.3.1 makes sense to me. >> >> As to the speed of making 2.x.0 , and 3.x.0 releases, really they are >> going to be a function of how much change is ready to go out. If we >> have enough changes to make a new minor version required then we >> increment it. As to supporting an ever growing number of branches, >> this will be a challenge, I'm sure we'll find a good balance between >> release frequency and new feature versions. >> >> Cheers, >> Jamie >> >> On Tue, Jan 15, 2013 at 5:46 PM, Christian Schneider >> <[email protected]> wrote: >> > Basically I agree but the question is what time we should aim for >> between >> > releases. >> > >> > A too short time period floods with releases that we all have to >> support for >> > some time. >> > A too long period makes people wait too long for features. >> > >> > I propose to have about 3 months between minor releases. So if we >> support >> > each release for a year we have about 4 releases to support in parallel. >> > >> > What do you think is a good period and support time? >> > >> > Christian >> > >> > Am 15.01.2013 17:51, schrieb Andreas Pieber: >> > >> >> maybe the solution should rather be increasing the speed of the minor >> >> releases; as long as we keep to semver.org I don't see any problems by >> >> it. >> >> >> >> Kind regards, >> >> Andreas >> >> >> >> On Tue, Jan 15, 2013 at 5:46 PM, Ioannis Canellos <[email protected]> >> >> wrote: >> >>> >> >>> +1 on creating a 2.4 branch. >> >>> Personally I am ok at adding new features on micro releases as long as >> >>> they >> >>> don't change the API, especially considering the speed at which we >> bring >> >>> out new major and minor ones. >> >>> >> >>> -- >> >>> *Ioannis Canellos* >> >>> * >> >>> >> >>> ** >> >>> Blog: http://iocanel.blogspot.com >> >>> ** >> >>> Twitter: iocanel >> >>> * >> > >> > >> > >> > -- >> > Christian Schneider >> > http://www.liquid-reality.de >> > >> > Open Source Architect >> > Talend Application Integration Division http://www.talend.com >> > >> > > > > -- > > Apache Karaf <http://karaf.apache.org/> Committer & PMC > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & > Project Lead > OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> > Commiter & Project Lead > blog <http://notizblog.nierbeck.de/> > -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project Lead blog <http://notizblog.nierbeck.de/>
