You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Andreas Pieber <an...@gmail.com> on 2013/01/15 17:10:42 UTC
Create Karaf 2.4.x branch
Hey Guys,
I would like to commit Karaf-1563 [1] to the 2.x line; but the only
branch available now is 2.3.x; while I know that a common argument now
will be that we should rather focus on 3.x I simply don't like the
idea to apply new features to micro releases. Those should always be
stable and new features simply cant gurantee this!
Kind regards,
Andreas
[1] https://issues.apache.org/jira/browse/KARAF-1563
Re: [PROPOSAL] Karaf release policy and branches
Posted by Andreas Pieber <an...@gmail.com>.
I think so too. If we ONLY backport real bugs and nothing else it would be
quite minimal imho. Let the branches grow as needed :-)
Kind regards, Andreas
On Jan 16, 2013 6:09 PM, "Jean-Baptiste Onofré" <jb...@nanthrax.net> wrote:
> 2.2.10 is a kind of particular, because it should have been a minor
> release (and not a micro).
>
> Anyway, stop working on it and support is not the same thing IMHO.
>
> Let say, we get 2.4 out:
> - we will work on 2.x branch (for 2.4.0, 2.5.0-SNAPSHOT, etc)
> - we can "for transition purpose" support 2.3.x and 2.2.x: it's just bug
> fixes on those branches.
>
> WDYT ?
>
> Regards
> JB
>
> On 01/16/2013 05:57 PM, Ioannis Canellos wrote:
>
>> Currently we are at 2.3.0 and 2.2.10. Does it mean that if we get out 2.4
>> to provide new features to our users, we will stop working on 2.2.x?
>> How would this work when we get 3.0.0 out?
>>
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: [PROPOSAL] Karaf release policy and branches
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
2.2.10 is a kind of particular, because it should have been a minor
release (and not a micro).
Anyway, stop working on it and support is not the same thing IMHO.
Let say, we get 2.4 out:
- we will work on 2.x branch (for 2.4.0, 2.5.0-SNAPSHOT, etc)
- we can "for transition purpose" support 2.3.x and 2.2.x: it's just bug
fixes on those branches.
WDYT ?
Regards
JB
On 01/16/2013 05:57 PM, Ioannis Canellos wrote:
> Currently we are at 2.3.0 and 2.2.10. Does it mean that if we get out 2.4
> to provide new features to our users, we will stop working on 2.2.x?
> How would this work when we get 3.0.0 out?
>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [PROPOSAL] Karaf release policy and branches
Posted by Ioannis Canellos <io...@gmail.com>.
Currently we are at 2.3.0 and 2.2.10. Does it mean that if we get out 2.4
to provide new features to our users, we will stop working on 2.2.x?
How would this work when we get 3.0.0 out?
--
*Ioannis Canellos*
*
**
Blog: http://iocanel.blogspot.com
**
Twitter: iocanel
*
Re: [PROPOSAL] Karaf release policy and branches
Posted by Achim Nierbeck <bc...@googlemail.com>.
I fully agree
+1 (binding)
regards, Achim
2013/1/16 Jean-Baptiste Onofré <jb...@nanthrax.net>
> Regarding the discussion, here's my proposal:
>
> - trunk stays as it is
> - I create karaf-2.x branch that will contain 2.x minor releases: 2.4.0,
> 2.5.0, 2.6.0
> - the "micro" branches will be created only when necessary
> - karaf-2.2.x and karaf-2.3.x stay as they are (as we will have a 2.3.1
> and we have 2.2.x releases)
>
> We maintain the latest two stable releases (currently 2.3.0 and 2.2.10 for
> instance).
>
> Micro releases should be really to fix only major bugs. We should focus on
> minor releases.
>
> If we are agree with that, I will do that this evening (my time, PCT).
>
> WDYT ?
>
> Regards
> JB
>
> On 01/15/2013 05:10 PM, Andreas Pieber wrote:
>
>> Hey Guys,
>>
>> I would like to commit Karaf-1563 [1] to the 2.x line; but the only
>> branch available now is 2.3.x; while I know that a common argument now
>> will be that we should rather focus on 3.x I simply don't like the
>> idea to apply new features to micro releases. Those should always be
>> stable and new features simply cant gurantee this!
>>
>> Kind regards,
>> Andreas
>>
>> [1] https://issues.apache.org/**jira/browse/KARAF-1563<https://issues.apache.org/jira/browse/KARAF-1563>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - 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/>
[PROPOSAL] Karaf release policy and branches
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Regarding the discussion, here's my proposal:
- trunk stays as it is
- I create karaf-2.x branch that will contain 2.x minor releases: 2.4.0,
2.5.0, 2.6.0
- the "micro" branches will be created only when necessary
- karaf-2.2.x and karaf-2.3.x stay as they are (as we will have a 2.3.1
and we have 2.2.x releases)
We maintain the latest two stable releases (currently 2.3.0 and 2.2.10
for instance).
Micro releases should be really to fix only major bugs. We should focus
on minor releases.
If we are agree with that, I will do that this evening (my time, PCT).
WDYT ?
Regards
JB
On 01/15/2013 05:10 PM, Andreas Pieber wrote:
> Hey Guys,
>
> I would like to commit Karaf-1563 [1] to the 2.x line; but the only
> branch available now is 2.3.x; while I know that a common argument now
> will be that we should rather focus on 3.x I simply don't like the
> idea to apply new features to micro releases. Those should always be
> stable and new features simply cant gurantee this!
>
> Kind regards,
> Andreas
>
> [1] https://issues.apache.org/jira/browse/KARAF-1563
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Create Karaf 2.4.x branch
Posted by Achim Nierbeck <bc...@googlemail.com>.
To my understanding the bugfix is just waiting to be applied.
Therefore waiting for "another two month" isn't necessary, so we might
very well just switch now.
Though releasing a 2.3.1 first is fine with me, which would result in a 2
month delay for the back port then ;)
Just my .02 cents
Achim
Am 15.01.2013 20:46 schrieb "Jean-Baptiste Onofré" <jb...@nanthrax.net>:
> Just another thing: if we decide to "speed up" the minor number versioning
> (more 2.5.0, 2.6.0, etc, which looks like a good idea to me), I think that
> it makes sense to create a karaf-2.x.x branch in that case (and "minor"
> branches only when it's required).
>
> My $.02
>
> Regards
> JB
>
> On 01/15/2013 05:53 PM, Achim Nierbeck wrote:
>
>> +1, and actually I think we might just skip 2.3.1 and call it a 2.4 after
>> this one is applied :D
>>
>> what do you think
>>
>> regards, Achim
>>
>>
>> 2013/1/15 Ioannis Canellos <io...@gmail.com>
>>
>> +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é
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Create Karaf 2.4.x branch
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Just another thing: if we decide to "speed up" the minor number
versioning (more 2.5.0, 2.6.0, etc, which looks like a good idea to me),
I think that it makes sense to create a karaf-2.x.x branch in that case
(and "minor" branches only when it's required).
My $.02
Regards
JB
On 01/15/2013 05:53 PM, Achim Nierbeck wrote:
> +1, and actually I think we might just skip 2.3.1 and call it a 2.4 after
> this one is applied :D
>
> what do you think
>
> regards, Achim
>
>
> 2013/1/15 Ioannis Canellos <io...@gmail.com>
>
>> +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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Create Karaf 2.4.x branch
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi guys,
my proposal would be to release 2.3.1 asap (including new Aries version)
and create 2.4.x just after.
Regards
JB
On 01/15/2013 05:53 PM, Achim Nierbeck wrote:
> +1, and actually I think we might just skip 2.3.1 and call it a 2.4 after
> this one is applied :D
>
> what do you think
>
> regards, Achim
>
>
> 2013/1/15 Ioannis Canellos <io...@gmail.com>
>
>> +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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Create Karaf 2.4.x branch
Posted by Dan Tran <da...@gmail.com>.
I would rather pickup 2.3.1 in the next 2 weeks as planned, rather
than another 2 months. :-) for 2.4
-D
On Tue, Jan 15, 2013 at 9:10 AM, Andreas Pieber <an...@gmail.com> wrote:
> Actually I would even prefer Achims proposal. Since we almost always
> add new features this would make the transition ways more logical.
> Maybe we should also combine this with timed released (2 months?).
> Micros are only bug-fix backports and we can cut those as required.
>
> Kind regards,
> Andreas
>
> On Tue, Jan 15, 2013 at 5:53 PM, Achim Nierbeck <bc...@googlemail.com> wrote:
>> +1, and actually I think we might just skip 2.3.1 and call it a 2.4 after
>> this one is applied :D
>>
>> what do you think
>>
>> regards, Achim
>>
>>
>> 2013/1/15 Ioannis Canellos <io...@gmail.com>
>>
>>> +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
>>> *
>>>
>>
>>
>>
>> --
>>
>> 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/>
Re: Create Karaf 2.4.x branch
Posted by Ioannis Canellos <io...@gmail.com>.
Even better.
--
*Ioannis Canellos*
*
**
Blog: http://iocanel.blogspot.com
**
Twitter: iocanel
*
Re: Create Karaf 2.4.x branch
Posted by Andreas Pieber <an...@gmail.com>.
Actually I would even prefer Achims proposal. Since we almost always
add new features this would make the transition ways more logical.
Maybe we should also combine this with timed released (2 months?).
Micros are only bug-fix backports and we can cut those as required.
Kind regards,
Andreas
On Tue, Jan 15, 2013 at 5:53 PM, Achim Nierbeck <bc...@googlemail.com> wrote:
> +1, and actually I think we might just skip 2.3.1 and call it a 2.4 after
> this one is applied :D
>
> what do you think
>
> regards, Achim
>
>
> 2013/1/15 Ioannis Canellos <io...@gmail.com>
>
>> +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
>> *
>>
>
>
>
> --
>
> 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/>
Re: Create Karaf 2.4.x branch
Posted by Achim Nierbeck <bc...@googlemail.com>.
+1, and actually I think we might just skip 2.3.1 and call it a 2.4 after
this one is applied :D
what do you think
regards, Achim
2013/1/15 Ioannis Canellos <io...@gmail.com>
> +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
> *
>
--
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/>
Re: Create Karaf 2.4.x branch
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 <io...@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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Create Karaf 2.4.x branch
Posted by Achim Nierbeck <bc...@googlemail.com>.
Oh, I forgot, it's this issue I was talking of :)
https://issues.apache.org/jira/browse/KARAF-2118
2013/1/16 Achim Nierbeck <bc...@googlemail.com>
> 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. <ja...@gmail.com>
>
> 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 <io...@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
>> >
>>
>
>
>
> --
>
> 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/>
Re: Create Karaf 2.4.x branch
Posted by Achim Nierbeck <bc...@googlemail.com>.
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. <ja...@gmail.com>
> 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 <io...@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
> >
>
--
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/>
Re: Create Karaf 2.4.x branch
Posted by "Jamie G." <ja...@gmail.com>.
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 <io...@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
>
Re: Create Karaf 2.4.x branch
Posted by Christian Schneider <ch...@die-schneider.net>.
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 <io...@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
Re: Create Karaf 2.4.x branch
Posted by Andreas Pieber <an...@gmail.com>.
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 <io...@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
> *
Re: Create Karaf 2.4.x branch
Posted by Ioannis Canellos <io...@gmail.com>.
+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
*
Re: Create Karaf 2.4.x branch
Posted by Guillaume Nodet <gn...@gmail.com>.
Agreed, that would give me a good way to revert my console security things
i put in 2.3.x branch until i can find some more time to polish it.
So +1
On Tue, Jan 15, 2013 at 5:10 PM, Andreas Pieber <an...@gmail.com> wrote:
> Hey Guys,
>
> I would like to commit Karaf-1563 [1] to the 2.x line; but the only
> branch available now is 2.3.x; while I know that a common argument now
> will be that we should rather focus on 3.x I simply don't like the
> idea to apply new features to micro releases. Those should always be
> stable and new features simply cant gurantee this!
>
> Kind regards,
> Andreas
>
> [1] https://issues.apache.org/jira/browse/KARAF-1563
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com