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 <ch...@die-schneider.net> 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 <ioca...@gmail.com> >> 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 >
