karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: Create Karaf 2.4.x branch
Date Wed, 16 Jan 2013 08:10:58 GMT
Oh, I forgot, it's this issue I was talking of :)
https://issues.apache.org/jira/browse/KARAF-2118


2013/1/16 Achim Nierbeck <bcanhome@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. <jamie.goodyear@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
>> <chris@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 <iocanel@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/>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message