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/>
