It depends what you name "minor" releases.
If, by minor releases, we stand for 2.4, 2.5, 2.6, etc, I'm agree.
If, by minor releases, we stand for "micro releases" 2.2.10, 2.2.11,
etc, I disagree.
AFAIR, we decided to maintain:
- the current stable release (2.3.0)
- the previous stable branch release (2.2.10)
If we release 3.0.0, we will maintain "only" 3.0.0 and 2.3.0.
If we release 2.4.0 (and not yet 3.0.0), we will maintain "only" 2.4.0
and 2.3.0.
Regards
JB
On 01/16/2013 12:46 AM, Christian Schneider 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
*
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
