You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by Jean-Baptiste Onofré <jb...@nanthrax.net> on 2014/10/08 07:52:39 UTC
[PROPOSAL] Karaf release cycle
Hi all,
Users complained about the variable and long delays between Karaf
releases. It's a fair comment and it's something that we have to improve.
I propose the following new policy about the releases cycle:
- for "active" branches (3.0.x and 2.4.x), I propose a release every 6
weeks, with maximum extend to 8 weeks.
- for "eol" and "maintenance" branches (2.2.x and 2.3.x), it's "on
demand", no strong cycle there.
WDYT ?
If everybody agrees, I will update the releases schedule page on the
website.
Regards
JB
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [PROPOSAL] Karaf release cycle
Posted by Christoph Gritschenberger <ch...@gmail.com>.
+1
And as for third-party dependencies I think there are two possible
scenarios:
1) a library-upgrade fixes an issue that was already present in the
previous release:
--> screw it and postpone the lib-upgrade for the next-release
2) a library-upgrade causes a regression, i.e. a bug that was *not*
present in the previous release:
--> revert the lib-upgrade and release without the library-upgrade
kind regards,
Christoph
On 08/10/14 10:46, Jamie G. wrote:
> +1
>
> There will always be another upstream fix to wait for, a short Karaf
> update cycle seems to be the best approach to avoiding extended
> delays.
>
> --J
>
> On Wed, Oct 8, 2014 at 4:55 AM, Achim Nierbeck <bc...@googlemail.com> wrote:
>> Hi,
>>
>> I'm in big favor of having a hard release cycle on 6 weeks (minimum I'd
>> actually prefer 4 ;) )
>> Regarding the thoughts about 3party dependencies, actually it's the reason
>> we don't get our own bugfixes out fast right now.
>> Actually I'd say screw it. No more waiting for 3rd party dependencies ...
>> get the stuff out fast cause 4-6 weeks later you have the next
>> release picking up the issue.
>>
>> regards, Achim
>>
>>
>> 2014-10-08 8:18 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>>>
>>> That's why we have an extend of 2 weeks to deal with other projects.
>>>
>>> Regards
>>> JB
>>>
>>> On 10/08/2014 08:16 AM, Christian Schneider wrote:
>>>>
>>>> Generally I agree that we should aim for such a cycle.
>>>> I only hope it is possible as we depend a lot on other projects that we
>>>> bundle. So a lot of the time a release waits on fixes or releases in
>>>> upstream projects.
>>>>
>>>> Christian
>>>>
>>>> Am 08.10.2014 07:52, schrieb Jean-Baptiste Onofré:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Users complained about the variable and long delays between Karaf
>>>>> releases. It's a fair comment and it's something that we have to
>>>>> improve.
>>>>>
>>>>> I propose the following new policy about the releases cycle:
>>>>> - for "active" branches (3.0.x and 2.4.x), I propose a release every 6
>>>>> weeks, with maximum extend to 8 weeks.
>>>>> - for "eol" and "maintenance" branches (2.2.x and 2.3.x), it's "on
>>>>> demand", no strong cycle there.
>>>>>
>>>>> WDYT ?
>>>>>
>>>>> If everybody agrees, I will update the releases schedule page on the
>>>>> website.
>>>>>
>>>>> Regards
>>>>> JB
>>>>
>>>>
>>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>
>>
>>
>>
>> --
>>
>> Apache Member
>> Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
>> Project Lead
>> blog <http://notizblog.nierbeck.de/>
>>
>> Software Architect / Project Manager / Scrum Master
>>
Re: [PROPOSAL] Karaf release cycle
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi Charlie,
for one, we already have those for snapshots :)
But, for a release Process this wouldn't work due to 2 major "blockers".
1) The artifacts are required to be signed. And signing only works for
Humans afaik (but I might be wrong on that ;) )
2) Every artifact / release needs to be voted on and therefore you'd need
to wait 72h for a vote to close, with at least 3 binding votes. Now that is
the biggest blocker as far as I'm concerned.
Therefore even though the idea is tempting and interesting it won't work
for us.
One might argue to do this with unsigned unreleased but tagged snapshot
versions ...
regards, Achim
2014-10-08 11:33 GMT+02:00 Charlie Mordant <cm...@gmail.com>:
> Hi,
> +1 for a short lifecycle.
>
> I'm not totally for what I'll ask but it's an alternative solution:
> What about continuous deployement?
> A Jenkins build pipeline that will trigger Jira ticket resolution then
> releasing Karaf if all tests pass?
> I really don't know if it's a viable solution, but it would make the thing
> :).
>
> Best regards,
>
> 2014-10-08 10:46 GMT+02:00 Jamie G. <ja...@gmail.com>:
>
> +1
>>
>> There will always be another upstream fix to wait for, a short Karaf
>> update cycle seems to be the best approach to avoiding extended
>> delays.
>>
>> --J
>>
>> On Wed, Oct 8, 2014 at 4:55 AM, Achim Nierbeck <bc...@googlemail.com>
>> wrote:
>> > Hi,
>> >
>> > I'm in big favor of having a hard release cycle on 6 weeks (minimum I'd
>> > actually prefer 4 ;) )
>> > Regarding the thoughts about 3party dependencies, actually it's the
>> reason
>> > we don't get our own bugfixes out fast right now.
>> > Actually I'd say screw it. No more waiting for 3rd party dependencies
>> ...
>> > get the stuff out fast cause 4-6 weeks later you have the next
>> > release picking up the issue.
>> >
>> > regards, Achim
>> >
>> >
>> > 2014-10-08 8:18 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>> >>
>> >> That's why we have an extend of 2 weeks to deal with other projects.
>> >>
>> >> Regards
>> >> JB
>> >>
>> >> On 10/08/2014 08:16 AM, Christian Schneider wrote:
>> >>>
>> >>> Generally I agree that we should aim for such a cycle.
>> >>> I only hope it is possible as we depend a lot on other projects that
>> we
>> >>> bundle. So a lot of the time a release waits on fixes or releases in
>> >>> upstream projects.
>> >>>
>> >>> Christian
>> >>>
>> >>> Am 08.10.2014 07:52, schrieb Jean-Baptiste Onofré:
>> >>>>
>> >>>> Hi all,
>> >>>>
>> >>>> Users complained about the variable and long delays between Karaf
>> >>>> releases. It's a fair comment and it's something that we have to
>> >>>> improve.
>> >>>>
>> >>>> I propose the following new policy about the releases cycle:
>> >>>> - for "active" branches (3.0.x and 2.4.x), I propose a release every
>> 6
>> >>>> weeks, with maximum extend to 8 weeks.
>> >>>> - for "eol" and "maintenance" branches (2.2.x and 2.3.x), it's "on
>> >>>> demand", no strong cycle there.
>> >>>>
>> >>>> WDYT ?
>> >>>>
>> >>>> If everybody agrees, I will update the releases schedule page on the
>> >>>> website.
>> >>>>
>> >>>> Regards
>> >>>> JB
>> >>>
>> >>>
>> >>>
>> >>
>> >> --
>> >> Jean-Baptiste Onofré
>> >> jbonofre@apache.org
>> >> http://blog.nanthrax.net
>> >> Talend - http://www.talend.com
>> >
>> >
>> >
>> >
>> > --
>> >
>> > Apache Member
>> > Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>> Committer &
>> > Project Lead
>> > blog <http://notizblog.nierbeck.de/>
>> >
>> > Software Architect / Project Manager / Scrum Master
>> >
>>
>
>
>
> --
> Charlie Mordant
>
> Full OSGI/EE stack made with Karaf:
> https://github.com/OsgiliathEnterprise/net.osgiliath.parent
>
--
Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Software Architect / Project Manager / Scrum Master
Re: [PROPOSAL] Karaf release cycle
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
This is for apache foundation, but don't forget the engagements of the
apache license (in terms of legal).
Regards
JB
On 10/17/2014 01:24 PM, Ioan Eugen Stan wrote:
> Hi,
>
> 2014-10-08 13:24 GMT+03:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>> No,
>>
>> it's not Apache compliant ;)
>>
>> An Apache release has to respect rules (verification, etc): sign, legal
>> checks, etc.
>>
>> Regards
>> JB
>
> Technically, the Apache Foundation is only concerned about source
> releases. Binaries are just a convenience to users. See [1] section
> 'What is a Valid Release Package?' . Users however are accustomed to
> binaries being available . It makes it easy for projects to attract
> users this way also.
>
> [1] http://www.apache.org/dev/release-publishing#goal
>
>
>> On 10/08/2014 12:20 PM, Charlie Mordant wrote:
>>>
>>> Hi Jean-Baptiste,
>>>
>>> I'm not speaking about nightlies/snapshot's, but real Maven Central
>>> releases (with a X.Y.Z+1 version), continuous delivery aims to release
>>> in production, not in a testing/snapshots env.
>>>
>>> The challenge is in deciding when to fire a release: a major/blocking
>>> Jira resolved, a code quality reached, 4 weeks after the last... And how
>>> to ensure the stability of the product (80% test coverage and 90 Itest?).
>>>
>>> It's more than a nightly, as it is not a daily baked product and more a
>>> decided one, the thing is that it is fully automated.
>>>
>>> Regards
>>>
>>>
>>>
>>> 2014-10-08 11:46 GMT+02:00 Jean-Baptiste Onofré <jb@nanthrax.net
>>> <ma...@nanthrax.net>>:
>>>
>>> Hi Charlie,
>>>
>>> We already have Jenkins and nightly builds. But I'm not sure a lot
>>> of people uses/tests the SNAPSHOTs.
>>>
>>> Regards
>>> JB
>>>
>>> On 10/08/2014 11:33 AM, Charlie Mordant wrote:
>>>
>>> Hi,
>>> +1 for a short lifecycle.
>>>
>>> I'm not totally for what I'll ask but it's an alternative
>>> solution:
>>> What about continuous deployement?
>>> A Jenkins build pipeline that will trigger Jira ticket
>>> resolution then
>>> releasing Karaf if all tests pass?
>>> I really don't know if it's a viable solution, but it would make
>>> the
>>> thing :).
>>>
>>> Best regards,
>>>
>>> 2014-10-08 10:46 GMT+02:00 Jamie G. <jamie.goodyear@gmail.com
>>> <ma...@gmail.com>
>>> <mailto:jamie.goodyear@gmail.__com
>>> <ma...@gmail.com>>>:
>>>
>>> +1
>>>
>>> There will always be another upstream fix to wait for, a
>>> short Karaf
>>> update cycle seems to be the best approach to avoiding
>>> extended
>>> delays.
>>>
>>> --J
>>>
>>> On Wed, Oct 8, 2014 at 4:55 AM, Achim Nierbeck
>>> <bcanhome@googlemail.com <ma...@googlemail.com>
>>> <mailto:bcanhome@googlemail.__com
>>> <ma...@googlemail.com>>> wrote:
>>> > Hi,
>>> >
>>> > I'm in big favor of having a hard release cycle on 6 weeks
>>> (minimum I'd
>>> > actually prefer 4 ;) )
>>> > Regarding the thoughts about 3party dependencies,
>>> actually it's
>>> the reason
>>> > we don't get our own bugfixes out fast right now.
>>> > Actually I'd say screw it. No more waiting for 3rd party
>>> dependencies ...
>>> > get the stuff out fast cause 4-6 weeks later you have
>>> the next
>>> > release picking up the issue.
>>> >
>>> > regards, Achim
>>> >
>>> >
>>> > 2014-10-08 8:18 GMT+02:00 Jean-Baptiste Onofré
>>> <jb@nanthrax.net <ma...@nanthrax.net>
>>> <mailto:jb@nanthrax.net <ma...@nanthrax.net>>>:
>>>
>>>
>>> >>
>>> >> That's why we have an extend of 2 weeks to deal with
>>> other projects.
>>> >>
>>> >> Regards
>>> >> JB
>>> >>
>>> >> On 10/08/2014 08:16 AM, Christian Schneider wrote:
>>> >>>
>>> >>> Generally I agree that we should aim for such a cycle.
>>> >>> I only hope it is possible as we depend a lot on other
>>> projects
>>> that we
>>> >>> bundle. So a lot of the time a release waits on fixes or
>>> releases in
>>> >>> upstream projects.
>>> >>>
>>> >>> Christian
>>> >>>
>>> >>> Am 08.10.2014 07:52, schrieb Jean-Baptiste Onofré:
>>> >>>>
>>> >>>> Hi all,
>>> >>>>
>>> >>>> Users complained about the variable and long delays
>>> between Karaf
>>> >>>> releases. It's a fair comment and it's something that
>>> we have to
>>> >>>> improve.
>>> >>>>
>>> >>>> I propose the following new policy about the releases
>>> cycle:
>>> >>>> - for "active" branches (3.0.x and 2.4.x), I propose
>>> a release
>>> every 6
>>> >>>> weeks, with maximum extend to 8 weeks.
>>> >>>> - for "eol" and "maintenance" branches (2.2.x and
>>> 2.3.x), it's "on
>>> >>>> demand", no strong cycle there.
>>> >>>>
>>> >>>> WDYT ?
>>> >>>>
>>> >>>> If everybody agrees, I will update the releases
>>> schedule page
>>> on the
>>> >>>> website.
>>> >>>>
>>> >>>> Regards
>>> >>>> JB
>>> >>>
>>> >>>
>>> >>>
>>> >>
>>> >> --
>>> >> Jean-Baptiste Onofré
>>> >> jbonofre@apache.org <ma...@apache.org>
>>> <mailto:jbonofre@apache.org <ma...@apache.org>>
>>> >> http://blog.nanthrax.net
>>> >> Talend - http://www.talend.com
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> >
>>> > Apache Member
>>> > Apache Karaf <http://karaf.apache.org/> Committer & PMC
>>> > OPS4J Pax Web
>>> <http://wiki.ops4j.org/__display/paxweb/Pax+Web/
>>> <http://wiki.ops4j.org/display/paxweb/Pax+Web/>>
>>> Committer &
>>> > Project Lead
>>> > blog <http://notizblog.nierbeck.de/__>
>>> >
>>> > Software Architect / Project Manager / Scrum Master
>>> >
>>>
>>>
>>>
>>>
>>> --
>>> Charlie Mordant
>>>
>>> Full OSGI/EE stack made with Karaf:
>>> https://github.com/__OsgiliathEnterprise/net.__osgiliath.parent
>>> <https://github.com/OsgiliathEnterprise/net.osgiliath.parent>
>>>
>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org <ma...@apache.org>
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>>
>>>
>>>
>>> --
>>> Charlie Mordant
>>>
>>> Full OSGI/EE stack made with Karaf:
>>> https://github.com/OsgiliathEnterprise/net.osgiliath.parent
>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [PROPOSAL] Karaf release cycle
Posted by Ioan Eugen Stan <st...@gmail.com>.
Hi,
2014-10-08 13:24 GMT+03:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> No,
>
> it's not Apache compliant ;)
>
> An Apache release has to respect rules (verification, etc): sign, legal
> checks, etc.
>
> Regards
> JB
Technically, the Apache Foundation is only concerned about source
releases. Binaries are just a convenience to users. See [1] section
'What is a Valid Release Package?' . Users however are accustomed to
binaries being available . It makes it easy for projects to attract
users this way also.
[1] http://www.apache.org/dev/release-publishing#goal
> On 10/08/2014 12:20 PM, Charlie Mordant wrote:
>>
>> Hi Jean-Baptiste,
>>
>> I'm not speaking about nightlies/snapshot's, but real Maven Central
>> releases (with a X.Y.Z+1 version), continuous delivery aims to release
>> in production, not in a testing/snapshots env.
>>
>> The challenge is in deciding when to fire a release: a major/blocking
>> Jira resolved, a code quality reached, 4 weeks after the last... And how
>> to ensure the stability of the product (80% test coverage and 90 Itest?).
>>
>> It's more than a nightly, as it is not a daily baked product and more a
>> decided one, the thing is that it is fully automated.
>>
>> Regards
>>
>>
>>
>> 2014-10-08 11:46 GMT+02:00 Jean-Baptiste Onofré <jb@nanthrax.net
>> <ma...@nanthrax.net>>:
>>
>> Hi Charlie,
>>
>> We already have Jenkins and nightly builds. But I'm not sure a lot
>> of people uses/tests the SNAPSHOTs.
>>
>> Regards
>> JB
>>
>> On 10/08/2014 11:33 AM, Charlie Mordant wrote:
>>
>> Hi,
>> +1 for a short lifecycle.
>>
>> I'm not totally for what I'll ask but it's an alternative
>> solution:
>> What about continuous deployement?
>> A Jenkins build pipeline that will trigger Jira ticket
>> resolution then
>> releasing Karaf if all tests pass?
>> I really don't know if it's a viable solution, but it would make
>> the
>> thing :).
>>
>> Best regards,
>>
>> 2014-10-08 10:46 GMT+02:00 Jamie G. <jamie.goodyear@gmail.com
>> <ma...@gmail.com>
>> <mailto:jamie.goodyear@gmail.__com
>> <ma...@gmail.com>>>:
>>
>> +1
>>
>> There will always be another upstream fix to wait for, a
>> short Karaf
>> update cycle seems to be the best approach to avoiding
>> extended
>> delays.
>>
>> --J
>>
>> On Wed, Oct 8, 2014 at 4:55 AM, Achim Nierbeck
>> <bcanhome@googlemail.com <ma...@googlemail.com>
>> <mailto:bcanhome@googlemail.__com
>> <ma...@googlemail.com>>> wrote:
>> > Hi,
>> >
>> > I'm in big favor of having a hard release cycle on 6 weeks
>> (minimum I'd
>> > actually prefer 4 ;) )
>> > Regarding the thoughts about 3party dependencies,
>> actually it's
>> the reason
>> > we don't get our own bugfixes out fast right now.
>> > Actually I'd say screw it. No more waiting for 3rd party
>> dependencies ...
>> > get the stuff out fast cause 4-6 weeks later you have
>> the next
>> > release picking up the issue.
>> >
>> > regards, Achim
>> >
>> >
>> > 2014-10-08 8:18 GMT+02:00 Jean-Baptiste Onofré
>> <jb@nanthrax.net <ma...@nanthrax.net>
>> <mailto:jb@nanthrax.net <ma...@nanthrax.net>>>:
>>
>>
>> >>
>> >> That's why we have an extend of 2 weeks to deal with
>> other projects.
>> >>
>> >> Regards
>> >> JB
>> >>
>> >> On 10/08/2014 08:16 AM, Christian Schneider wrote:
>> >>>
>> >>> Generally I agree that we should aim for such a cycle.
>> >>> I only hope it is possible as we depend a lot on other
>> projects
>> that we
>> >>> bundle. So a lot of the time a release waits on fixes or
>> releases in
>> >>> upstream projects.
>> >>>
>> >>> Christian
>> >>>
>> >>> Am 08.10.2014 07:52, schrieb Jean-Baptiste Onofré:
>> >>>>
>> >>>> Hi all,
>> >>>>
>> >>>> Users complained about the variable and long delays
>> between Karaf
>> >>>> releases. It's a fair comment and it's something that
>> we have to
>> >>>> improve.
>> >>>>
>> >>>> I propose the following new policy about the releases
>> cycle:
>> >>>> - for "active" branches (3.0.x and 2.4.x), I propose
>> a release
>> every 6
>> >>>> weeks, with maximum extend to 8 weeks.
>> >>>> - for "eol" and "maintenance" branches (2.2.x and
>> 2.3.x), it's "on
>> >>>> demand", no strong cycle there.
>> >>>>
>> >>>> WDYT ?
>> >>>>
>> >>>> If everybody agrees, I will update the releases
>> schedule page
>> on the
>> >>>> website.
>> >>>>
>> >>>> Regards
>> >>>> JB
>> >>>
>> >>>
>> >>>
>> >>
>> >> --
>> >> Jean-Baptiste Onofré
>> >> jbonofre@apache.org <ma...@apache.org>
>> <mailto:jbonofre@apache.org <ma...@apache.org>>
>> >> http://blog.nanthrax.net
>> >> Talend - http://www.talend.com
>> >
>> >
>> >
>> >
>> > --
>> >
>> > Apache Member
>> > Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> > OPS4J Pax Web
>> <http://wiki.ops4j.org/__display/paxweb/Pax+Web/
>> <http://wiki.ops4j.org/display/paxweb/Pax+Web/>>
>> Committer &
>> > Project Lead
>> > blog <http://notizblog.nierbeck.de/__>
>> >
>> > Software Architect / Project Manager / Scrum Master
>> >
>>
>>
>>
>>
>> --
>> Charlie Mordant
>>
>> Full OSGI/EE stack made with Karaf:
>> https://github.com/__OsgiliathEnterprise/net.__osgiliath.parent
>> <https://github.com/OsgiliathEnterprise/net.osgiliath.parent>
>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org <ma...@apache.org>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>>
>>
>> --
>> Charlie Mordant
>>
>> Full OSGI/EE stack made with Karaf:
>> https://github.com/OsgiliathEnterprise/net.osgiliath.parent
>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
--
Ioan Eugen Stan
0720 898 747
Re: [PROPOSAL] Karaf release cycle
Posted by Charlie Mordant <cm...@gmail.com>.
Hum, okay :),
I didn't know there were IP reviewers at Apache (other than Apache-rat and
pgp), glad to hear !
Regards,
2014-10-08 12:24 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> No,
>
> it's not Apache compliant ;)
>
> An Apache release has to respect rules (verification, etc): sign, legal
> checks, etc.
>
> Regards
> JB
>
> On 10/08/2014 12:20 PM, Charlie Mordant wrote:
>
>> Hi Jean-Baptiste,
>>
>> I'm not speaking about nightlies/snapshot's, but real Maven Central
>> releases (with a X.Y.Z+1 version), continuous delivery aims to release
>> in production, not in a testing/snapshots env.
>>
>> The challenge is in deciding when to fire a release: a major/blocking
>> Jira resolved, a code quality reached, 4 weeks after the last... And how
>> to ensure the stability of the product (80% test coverage and 90 Itest?).
>>
>> It's more than a nightly, as it is not a daily baked product and more a
>> decided one, the thing is that it is fully automated.
>>
>> Regards
>>
>>
>>
>> 2014-10-08 11:46 GMT+02:00 Jean-Baptiste Onofré <jb@nanthrax.net
>> <ma...@nanthrax.net>>:
>>
>> Hi Charlie,
>>
>> We already have Jenkins and nightly builds. But I'm not sure a lot
>> of people uses/tests the SNAPSHOTs.
>>
>> Regards
>> JB
>>
>> On 10/08/2014 11:33 AM, Charlie Mordant wrote:
>>
>> Hi,
>> +1 for a short lifecycle.
>>
>> I'm not totally for what I'll ask but it's an alternative
>> solution:
>> What about continuous deployement?
>> A Jenkins build pipeline that will trigger Jira ticket
>> resolution then
>> releasing Karaf if all tests pass?
>> I really don't know if it's a viable solution, but it would make
>> the
>> thing :).
>>
>> Best regards,
>>
>> 2014-10-08 10:46 GMT+02:00 Jamie G. <jamie.goodyear@gmail.com
>> <ma...@gmail.com>
>> <mailto:jamie.goodyear@gmail.__com
>> <ma...@gmail.com>>>:
>>
>> +1
>>
>> There will always be another upstream fix to wait for, a
>> short Karaf
>> update cycle seems to be the best approach to avoiding
>> extended
>> delays.
>>
>> --J
>>
>> On Wed, Oct 8, 2014 at 4:55 AM, Achim Nierbeck
>> <bcanhome@googlemail.com <ma...@googlemail.com>
>> <mailto:bcanhome@googlemail.__com
>> <ma...@googlemail.com>>> wrote:
>> > Hi,
>> >
>> > I'm in big favor of having a hard release cycle on 6 weeks
>> (minimum I'd
>> > actually prefer 4 ;) )
>> > Regarding the thoughts about 3party dependencies,
>> actually it's
>> the reason
>> > we don't get our own bugfixes out fast right now.
>> > Actually I'd say screw it. No more waiting for 3rd party
>> dependencies ...
>> > get the stuff out fast cause 4-6 weeks later you have
>> the next
>> > release picking up the issue.
>> >
>> > regards, Achim
>> >
>> >
>> > 2014-10-08 8:18 GMT+02:00 Jean-Baptiste Onofré
>> <jb@nanthrax.net <ma...@nanthrax.net>
>> <mailto:jb@nanthrax.net <ma...@nanthrax.net>>>:
>>
>>
>> >>
>> >> That's why we have an extend of 2 weeks to deal with
>> other projects.
>> >>
>> >> Regards
>> >> JB
>> >>
>> >> On 10/08/2014 08:16 AM, Christian Schneider wrote:
>> >>>
>> >>> Generally I agree that we should aim for such a cycle.
>> >>> I only hope it is possible as we depend a lot on other
>> projects
>> that we
>> >>> bundle. So a lot of the time a release waits on fixes or
>> releases in
>> >>> upstream projects.
>> >>>
>> >>> Christian
>> >>>
>> >>> Am 08.10.2014 07:52, schrieb Jean-Baptiste Onofré:
>> >>>>
>> >>>> Hi all,
>> >>>>
>> >>>> Users complained about the variable and long delays
>> between Karaf
>> >>>> releases. It's a fair comment and it's something that
>> we have to
>> >>>> improve.
>> >>>>
>> >>>> I propose the following new policy about the releases
>> cycle:
>> >>>> - for "active" branches (3.0.x and 2.4.x), I propose
>> a release
>> every 6
>> >>>> weeks, with maximum extend to 8 weeks.
>> >>>> - for "eol" and "maintenance" branches (2.2.x and
>> 2.3.x), it's "on
>> >>>> demand", no strong cycle there.
>> >>>>
>> >>>> WDYT ?
>> >>>>
>> >>>> If everybody agrees, I will update the releases
>> schedule page
>> on the
>> >>>> website.
>> >>>>
>> >>>> Regards
>> >>>> JB
>> >>>
>> >>>
>> >>>
>> >>
>> >> --
>> >> Jean-Baptiste Onofré
>> >> jbonofre@apache.org <ma...@apache.org>
>> <mailto:jbonofre@apache.org <ma...@apache.org>>
>> >> http://blog.nanthrax.net
>> >> Talend - http://www.talend.com
>> >
>> >
>> >
>> >
>> > --
>> >
>> > Apache Member
>> > Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> > OPS4J Pax Web
>> <http://wiki.ops4j.org/__display/paxweb/Pax+Web/
>> <http://wiki.ops4j.org/display/paxweb/Pax+Web/>>
>> Committer &
>> > Project Lead
>> > blog <http://notizblog.nierbeck.de/__>
>> >
>> > Software Architect / Project Manager / Scrum Master
>> >
>>
>>
>>
>>
>> --
>> Charlie Mordant
>>
>> Full OSGI/EE stack made with Karaf:
>> https://github.com/__OsgiliathEnterprise/net.__osgiliath.parent
>> <https://github.com/OsgiliathEnterprise/net.osgiliath.parent>
>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org <ma...@apache.org>
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>>
>>
>>
>> --
>> Charlie Mordant
>>
>> Full OSGI/EE stack made with Karaf:
>> https://github.com/OsgiliathEnterprise/net.osgiliath.parent
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
Charlie Mordant
Full OSGI/EE stack made with Karaf:
https://github.com/OsgiliathEnterprise/net.osgiliath.parent
Re: [PROPOSAL] Karaf release cycle
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
No,
it's not Apache compliant ;)
An Apache release has to respect rules (verification, etc): sign, legal
checks, etc.
Regards
JB
On 10/08/2014 12:20 PM, Charlie Mordant wrote:
> Hi Jean-Baptiste,
>
> I'm not speaking about nightlies/snapshot's, but real Maven Central
> releases (with a X.Y.Z+1 version), continuous delivery aims to release
> in production, not in a testing/snapshots env.
>
> The challenge is in deciding when to fire a release: a major/blocking
> Jira resolved, a code quality reached, 4 weeks after the last... And how
> to ensure the stability of the product (80% test coverage and 90 Itest?).
>
> It's more than a nightly, as it is not a daily baked product and more a
> decided one, the thing is that it is fully automated.
>
> Regards
>
>
>
> 2014-10-08 11:46 GMT+02:00 Jean-Baptiste Onofré <jb@nanthrax.net
> <ma...@nanthrax.net>>:
>
> Hi Charlie,
>
> We already have Jenkins and nightly builds. But I'm not sure a lot
> of people uses/tests the SNAPSHOTs.
>
> Regards
> JB
>
> On 10/08/2014 11:33 AM, Charlie Mordant wrote:
>
> Hi,
> +1 for a short lifecycle.
>
> I'm not totally for what I'll ask but it's an alternative solution:
> What about continuous deployement?
> A Jenkins build pipeline that will trigger Jira ticket
> resolution then
> releasing Karaf if all tests pass?
> I really don't know if it's a viable solution, but it would make the
> thing :).
>
> Best regards,
>
> 2014-10-08 10:46 GMT+02:00 Jamie G. <jamie.goodyear@gmail.com
> <ma...@gmail.com>
> <mailto:jamie.goodyear@gmail.__com
> <ma...@gmail.com>>>:
>
> +1
>
> There will always be another upstream fix to wait for, a
> short Karaf
> update cycle seems to be the best approach to avoiding extended
> delays.
>
> --J
>
> On Wed, Oct 8, 2014 at 4:55 AM, Achim Nierbeck
> <bcanhome@googlemail.com <ma...@googlemail.com>
> <mailto:bcanhome@googlemail.__com
> <ma...@googlemail.com>>> wrote:
> > Hi,
> >
> > I'm in big favor of having a hard release cycle on 6 weeks
> (minimum I'd
> > actually prefer 4 ;) )
> > Regarding the thoughts about 3party dependencies,
> actually it's
> the reason
> > we don't get our own bugfixes out fast right now.
> > Actually I'd say screw it. No more waiting for 3rd party
> dependencies ...
> > get the stuff out fast cause 4-6 weeks later you have
> the next
> > release picking up the issue.
> >
> > regards, Achim
> >
> >
> > 2014-10-08 8:18 GMT+02:00 Jean-Baptiste Onofré
> <jb@nanthrax.net <ma...@nanthrax.net>
> <mailto:jb@nanthrax.net <ma...@nanthrax.net>>>:
>
> >>
> >> That's why we have an extend of 2 weeks to deal with
> other projects.
> >>
> >> Regards
> >> JB
> >>
> >> On 10/08/2014 08:16 AM, Christian Schneider wrote:
> >>>
> >>> Generally I agree that we should aim for such a cycle.
> >>> I only hope it is possible as we depend a lot on other
> projects
> that we
> >>> bundle. So a lot of the time a release waits on fixes or
> releases in
> >>> upstream projects.
> >>>
> >>> Christian
> >>>
> >>> Am 08.10.2014 07:52, schrieb Jean-Baptiste Onofré:
> >>>>
> >>>> Hi all,
> >>>>
> >>>> Users complained about the variable and long delays
> between Karaf
> >>>> releases. It's a fair comment and it's something that
> we have to
> >>>> improve.
> >>>>
> >>>> I propose the following new policy about the releases
> cycle:
> >>>> - for "active" branches (3.0.x and 2.4.x), I propose
> a release
> every 6
> >>>> weeks, with maximum extend to 8 weeks.
> >>>> - for "eol" and "maintenance" branches (2.2.x and
> 2.3.x), it's "on
> >>>> demand", no strong cycle there.
> >>>>
> >>>> WDYT ?
> >>>>
> >>>> If everybody agrees, I will update the releases
> schedule page
> on the
> >>>> website.
> >>>>
> >>>> Regards
> >>>> JB
> >>>
> >>>
> >>>
> >>
> >> --
> >> Jean-Baptiste Onofré
> >> jbonofre@apache.org <ma...@apache.org>
> <mailto:jbonofre@apache.org <ma...@apache.org>>
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >
> >
> >
> >
> > --
> >
> > Apache Member
> > Apache Karaf <http://karaf.apache.org/> Committer & PMC
> > OPS4J Pax Web
> <http://wiki.ops4j.org/__display/paxweb/Pax+Web/
> <http://wiki.ops4j.org/display/paxweb/Pax+Web/>>
> Committer &
> > Project Lead
> > blog <http://notizblog.nierbeck.de/__>
> >
> > Software Architect / Project Manager / Scrum Master
> >
>
>
>
>
> --
> Charlie Mordant
>
> Full OSGI/EE stack made with Karaf:
> https://github.com/__OsgiliathEnterprise/net.__osgiliath.parent
> <https://github.com/OsgiliathEnterprise/net.osgiliath.parent>
>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org <ma...@apache.org>
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
>
>
>
> --
> Charlie Mordant
>
> Full OSGI/EE stack made with Karaf:
> https://github.com/OsgiliathEnterprise/net.osgiliath.parent
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [PROPOSAL] Karaf release cycle
Posted by Charlie Mordant <cm...@gmail.com>.
Hi Jean-Baptiste,
I'm not speaking about nightlies/snapshot's, but real Maven Central
releases (with a X.Y.Z+1 version), continuous delivery aims to release in
production, not in a testing/snapshots env.
The challenge is in deciding when to fire a release: a major/blocking Jira
resolved, a code quality reached, 4 weeks after the last... And how to
ensure the stability of the product (80% test coverage and 90 Itest?).
It's more than a nightly, as it is not a daily baked product and more a
decided one, the thing is that it is fully automated.
Regards
2014-10-08 11:46 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> Hi Charlie,
>
> We already have Jenkins and nightly builds. But I'm not sure a lot of
> people uses/tests the SNAPSHOTs.
>
> Regards
> JB
>
> On 10/08/2014 11:33 AM, Charlie Mordant wrote:
>
>> Hi,
>> +1 for a short lifecycle.
>>
>> I'm not totally for what I'll ask but it's an alternative solution:
>> What about continuous deployement?
>> A Jenkins build pipeline that will trigger Jira ticket resolution then
>> releasing Karaf if all tests pass?
>> I really don't know if it's a viable solution, but it would make the
>> thing :).
>>
>> Best regards,
>>
>> 2014-10-08 10:46 GMT+02:00 Jamie G. <jamie.goodyear@gmail.com
>> <ma...@gmail.com>>:
>>
>> +1
>>
>> There will always be another upstream fix to wait for, a short Karaf
>> update cycle seems to be the best approach to avoiding extended
>> delays.
>>
>> --J
>>
>> On Wed, Oct 8, 2014 at 4:55 AM, Achim Nierbeck
>> <bcanhome@googlemail.com <ma...@googlemail.com>> wrote:
>> > Hi,
>> >
>> > I'm in big favor of having a hard release cycle on 6 weeks
>> (minimum I'd
>> > actually prefer 4 ;) )
>> > Regarding the thoughts about 3party dependencies, actually it's
>> the reason
>> > we don't get our own bugfixes out fast right now.
>> > Actually I'd say screw it. No more waiting for 3rd party
>> dependencies ...
>> > get the stuff out fast cause 4-6 weeks later you have the next
>> > release picking up the issue.
>> >
>> > regards, Achim
>> >
>> >
>> > 2014-10-08 8:18 GMT+02:00 Jean-Baptiste Onofré <jb@nanthrax.net
>> <ma...@nanthrax.net>>:
>>
>> >>
>> >> That's why we have an extend of 2 weeks to deal with other
>> projects.
>> >>
>> >> Regards
>> >> JB
>> >>
>> >> On 10/08/2014 08:16 AM, Christian Schneider wrote:
>> >>>
>> >>> Generally I agree that we should aim for such a cycle.
>> >>> I only hope it is possible as we depend a lot on other projects
>> that we
>> >>> bundle. So a lot of the time a release waits on fixes or
>> releases in
>> >>> upstream projects.
>> >>>
>> >>> Christian
>> >>>
>> >>> Am 08.10.2014 07:52, schrieb Jean-Baptiste Onofré:
>> >>>>
>> >>>> Hi all,
>> >>>>
>> >>>> Users complained about the variable and long delays between
>> Karaf
>> >>>> releases. It's a fair comment and it's something that we have to
>> >>>> improve.
>> >>>>
>> >>>> I propose the following new policy about the releases cycle:
>> >>>> - for "active" branches (3.0.x and 2.4.x), I propose a release
>> every 6
>> >>>> weeks, with maximum extend to 8 weeks.
>> >>>> - for "eol" and "maintenance" branches (2.2.x and 2.3.x), it's
>> "on
>> >>>> demand", no strong cycle there.
>> >>>>
>> >>>> WDYT ?
>> >>>>
>> >>>> If everybody agrees, I will update the releases schedule page
>> on the
>> >>>> website.
>> >>>>
>> >>>> Regards
>> >>>> JB
>> >>>
>> >>>
>> >>>
>> >>
>> >> --
>> >> Jean-Baptiste Onofré
>> >> jbonofre@apache.org <ma...@apache.org>
>> >> http://blog.nanthrax.net
>> >> Talend - http://www.talend.com
>> >
>> >
>> >
>> >
>> > --
>> >
>> > Apache Member
>> > Apache Karaf <http://karaf.apache.org/> Committer & PMC
>> > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
>> Committer &
>> > Project Lead
>> > blog <http://notizblog.nierbeck.de/>
>> >
>> > Software Architect / Project Manager / Scrum Master
>> >
>>
>>
>>
>>
>> --
>> Charlie Mordant
>>
>> Full OSGI/EE stack made with Karaf:
>> https://github.com/OsgiliathEnterprise/net.osgiliath.parent
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
Charlie Mordant
Full OSGI/EE stack made with Karaf:
https://github.com/OsgiliathEnterprise/net.osgiliath.parent
Re: [PROPOSAL] Karaf release cycle
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Charlie,
We already have Jenkins and nightly builds. But I'm not sure a lot of
people uses/tests the SNAPSHOTs.
Regards
JB
On 10/08/2014 11:33 AM, Charlie Mordant wrote:
> Hi,
> +1 for a short lifecycle.
>
> I'm not totally for what I'll ask but it's an alternative solution:
> What about continuous deployement?
> A Jenkins build pipeline that will trigger Jira ticket resolution then
> releasing Karaf if all tests pass?
> I really don't know if it's a viable solution, but it would make the
> thing :).
>
> Best regards,
>
> 2014-10-08 10:46 GMT+02:00 Jamie G. <jamie.goodyear@gmail.com
> <ma...@gmail.com>>:
>
> +1
>
> There will always be another upstream fix to wait for, a short Karaf
> update cycle seems to be the best approach to avoiding extended
> delays.
>
> --J
>
> On Wed, Oct 8, 2014 at 4:55 AM, Achim Nierbeck
> <bcanhome@googlemail.com <ma...@googlemail.com>> wrote:
> > Hi,
> >
> > I'm in big favor of having a hard release cycle on 6 weeks
> (minimum I'd
> > actually prefer 4 ;) )
> > Regarding the thoughts about 3party dependencies, actually it's
> the reason
> > we don't get our own bugfixes out fast right now.
> > Actually I'd say screw it. No more waiting for 3rd party
> dependencies ...
> > get the stuff out fast cause 4-6 weeks later you have the next
> > release picking up the issue.
> >
> > regards, Achim
> >
> >
> > 2014-10-08 8:18 GMT+02:00 Jean-Baptiste Onofré <jb@nanthrax.net
> <ma...@nanthrax.net>>:
> >>
> >> That's why we have an extend of 2 weeks to deal with other projects.
> >>
> >> Regards
> >> JB
> >>
> >> On 10/08/2014 08:16 AM, Christian Schneider wrote:
> >>>
> >>> Generally I agree that we should aim for such a cycle.
> >>> I only hope it is possible as we depend a lot on other projects
> that we
> >>> bundle. So a lot of the time a release waits on fixes or
> releases in
> >>> upstream projects.
> >>>
> >>> Christian
> >>>
> >>> Am 08.10.2014 07:52, schrieb Jean-Baptiste Onofré:
> >>>>
> >>>> Hi all,
> >>>>
> >>>> Users complained about the variable and long delays between Karaf
> >>>> releases. It's a fair comment and it's something that we have to
> >>>> improve.
> >>>>
> >>>> I propose the following new policy about the releases cycle:
> >>>> - for "active" branches (3.0.x and 2.4.x), I propose a release
> every 6
> >>>> weeks, with maximum extend to 8 weeks.
> >>>> - for "eol" and "maintenance" branches (2.2.x and 2.3.x), it's "on
> >>>> demand", no strong cycle there.
> >>>>
> >>>> WDYT ?
> >>>>
> >>>> If everybody agrees, I will update the releases schedule page
> on the
> >>>> website.
> >>>>
> >>>> Regards
> >>>> JB
> >>>
> >>>
> >>>
> >>
> >> --
> >> Jean-Baptiste Onofré
> >> jbonofre@apache.org <ma...@apache.org>
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >
> >
> >
> >
> > --
> >
> > Apache Member
> > Apache Karaf <http://karaf.apache.org/> Committer & PMC
> > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
> Committer &
> > Project Lead
> > blog <http://notizblog.nierbeck.de/>
> >
> > Software Architect / Project Manager / Scrum Master
> >
>
>
>
>
> --
> Charlie Mordant
>
> Full OSGI/EE stack made with Karaf:
> https://github.com/OsgiliathEnterprise/net.osgiliath.parent
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [PROPOSAL] Karaf release cycle
Posted by Charlie Mordant <cm...@gmail.com>.
Hi,
+1 for a short lifecycle.
I'm not totally for what I'll ask but it's an alternative solution:
What about continuous deployement?
A Jenkins build pipeline that will trigger Jira ticket resolution then
releasing Karaf if all tests pass?
I really don't know if it's a viable solution, but it would make the thing
:).
Best regards,
2014-10-08 10:46 GMT+02:00 Jamie G. <ja...@gmail.com>:
> +1
>
> There will always be another upstream fix to wait for, a short Karaf
> update cycle seems to be the best approach to avoiding extended
> delays.
>
> --J
>
> On Wed, Oct 8, 2014 at 4:55 AM, Achim Nierbeck <bc...@googlemail.com>
> wrote:
> > Hi,
> >
> > I'm in big favor of having a hard release cycle on 6 weeks (minimum I'd
> > actually prefer 4 ;) )
> > Regarding the thoughts about 3party dependencies, actually it's the
> reason
> > we don't get our own bugfixes out fast right now.
> > Actually I'd say screw it. No more waiting for 3rd party dependencies ...
> > get the stuff out fast cause 4-6 weeks later you have the next
> > release picking up the issue.
> >
> > regards, Achim
> >
> >
> > 2014-10-08 8:18 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> >>
> >> That's why we have an extend of 2 weeks to deal with other projects.
> >>
> >> Regards
> >> JB
> >>
> >> On 10/08/2014 08:16 AM, Christian Schneider wrote:
> >>>
> >>> Generally I agree that we should aim for such a cycle.
> >>> I only hope it is possible as we depend a lot on other projects that we
> >>> bundle. So a lot of the time a release waits on fixes or releases in
> >>> upstream projects.
> >>>
> >>> Christian
> >>>
> >>> Am 08.10.2014 07:52, schrieb Jean-Baptiste Onofré:
> >>>>
> >>>> Hi all,
> >>>>
> >>>> Users complained about the variable and long delays between Karaf
> >>>> releases. It's a fair comment and it's something that we have to
> >>>> improve.
> >>>>
> >>>> I propose the following new policy about the releases cycle:
> >>>> - for "active" branches (3.0.x and 2.4.x), I propose a release every 6
> >>>> weeks, with maximum extend to 8 weeks.
> >>>> - for "eol" and "maintenance" branches (2.2.x and 2.3.x), it's "on
> >>>> demand", no strong cycle there.
> >>>>
> >>>> WDYT ?
> >>>>
> >>>> If everybody agrees, I will update the releases schedule page on the
> >>>> website.
> >>>>
> >>>> Regards
> >>>> JB
> >>>
> >>>
> >>>
> >>
> >> --
> >> Jean-Baptiste Onofré
> >> jbonofre@apache.org
> >> http://blog.nanthrax.net
> >> Talend - http://www.talend.com
> >
> >
> >
> >
> > --
> >
> > Apache Member
> > Apache Karaf <http://karaf.apache.org/> Committer & PMC
> > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer
> &
> > Project Lead
> > blog <http://notizblog.nierbeck.de/>
> >
> > Software Architect / Project Manager / Scrum Master
> >
>
--
Charlie Mordant
Full OSGI/EE stack made with Karaf:
https://github.com/OsgiliathEnterprise/net.osgiliath.parent
Re: [PROPOSAL] Karaf release cycle
Posted by "Jamie G." <ja...@gmail.com>.
+1
There will always be another upstream fix to wait for, a short Karaf
update cycle seems to be the best approach to avoiding extended
delays.
--J
On Wed, Oct 8, 2014 at 4:55 AM, Achim Nierbeck <bc...@googlemail.com> wrote:
> Hi,
>
> I'm in big favor of having a hard release cycle on 6 weeks (minimum I'd
> actually prefer 4 ;) )
> Regarding the thoughts about 3party dependencies, actually it's the reason
> we don't get our own bugfixes out fast right now.
> Actually I'd say screw it. No more waiting for 3rd party dependencies ...
> get the stuff out fast cause 4-6 weeks later you have the next
> release picking up the issue.
>
> regards, Achim
>
>
> 2014-10-08 8:18 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>>
>> That's why we have an extend of 2 weeks to deal with other projects.
>>
>> Regards
>> JB
>>
>> On 10/08/2014 08:16 AM, Christian Schneider wrote:
>>>
>>> Generally I agree that we should aim for such a cycle.
>>> I only hope it is possible as we depend a lot on other projects that we
>>> bundle. So a lot of the time a release waits on fixes or releases in
>>> upstream projects.
>>>
>>> Christian
>>>
>>> Am 08.10.2014 07:52, schrieb Jean-Baptiste Onofré:
>>>>
>>>> Hi all,
>>>>
>>>> Users complained about the variable and long delays between Karaf
>>>> releases. It's a fair comment and it's something that we have to
>>>> improve.
>>>>
>>>> I propose the following new policy about the releases cycle:
>>>> - for "active" branches (3.0.x and 2.4.x), I propose a release every 6
>>>> weeks, with maximum extend to 8 weeks.
>>>> - for "eol" and "maintenance" branches (2.2.x and 2.3.x), it's "on
>>>> demand", no strong cycle there.
>>>>
>>>> WDYT ?
>>>>
>>>> If everybody agrees, I will update the releases schedule page on the
>>>> website.
>>>>
>>>> Regards
>>>> JB
>>>
>>>
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>
>
>
>
> --
>
> Apache Member
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
> Project Lead
> blog <http://notizblog.nierbeck.de/>
>
> Software Architect / Project Manager / Scrum Master
>
Re: [PROPOSAL] Karaf release cycle
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi,
I'm in big favor of having a hard release cycle on 6 weeks (minimum I'd
actually prefer 4 ;) )
Regarding the thoughts about 3party dependencies, actually it's the reason
we don't get our own bugfixes out fast right now.
Actually I'd say screw it. No more waiting for 3rd party dependencies ...
get the stuff out fast cause 4-6 weeks later you have the next
release picking up the issue.
regards, Achim
2014-10-08 8:18 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> That's why we have an extend of 2 weeks to deal with other projects.
>
> Regards
> JB
>
> On 10/08/2014 08:16 AM, Christian Schneider wrote:
>
>> Generally I agree that we should aim for such a cycle.
>> I only hope it is possible as we depend a lot on other projects that we
>> bundle. So a lot of the time a release waits on fixes or releases in
>> upstream projects.
>>
>> Christian
>>
>> Am 08.10.2014 07:52, schrieb Jean-Baptiste Onofré:
>>
>>> Hi all,
>>>
>>> Users complained about the variable and long delays between Karaf
>>> releases. It's a fair comment and it's something that we have to improve.
>>>
>>> I propose the following new policy about the releases cycle:
>>> - for "active" branches (3.0.x and 2.4.x), I propose a release every 6
>>> weeks, with maximum extend to 8 weeks.
>>> - for "eol" and "maintenance" branches (2.2.x and 2.3.x), it's "on
>>> demand", no strong cycle there.
>>>
>>> WDYT ?
>>>
>>> If everybody agrees, I will update the releases schedule page on the
>>> website.
>>>
>>> Regards
>>> JB
>>>
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
--
Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Software Architect / Project Manager / Scrum Master
Re: [PROPOSAL] Karaf release cycle
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
That's why we have an extend of 2 weeks to deal with other projects.
Regards
JB
On 10/08/2014 08:16 AM, Christian Schneider wrote:
> Generally I agree that we should aim for such a cycle.
> I only hope it is possible as we depend a lot on other projects that we
> bundle. So a lot of the time a release waits on fixes or releases in
> upstream projects.
>
> Christian
>
> Am 08.10.2014 07:52, schrieb Jean-Baptiste Onofré:
>> Hi all,
>>
>> Users complained about the variable and long delays between Karaf
>> releases. It's a fair comment and it's something that we have to improve.
>>
>> I propose the following new policy about the releases cycle:
>> - for "active" branches (3.0.x and 2.4.x), I propose a release every 6
>> weeks, with maximum extend to 8 weeks.
>> - for "eol" and "maintenance" branches (2.2.x and 2.3.x), it's "on
>> demand", no strong cycle there.
>>
>> WDYT ?
>>
>> If everybody agrees, I will update the releases schedule page on the
>> website.
>>
>> Regards
>> JB
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [PROPOSAL] Karaf release cycle
Posted by Christian Schneider <ch...@die-schneider.net>.
Generally I agree that we should aim for such a cycle.
I only hope it is possible as we depend a lot on other projects that we
bundle. So a lot of the time a release waits on fixes or releases in
upstream projects.
Christian
Am 08.10.2014 07:52, schrieb Jean-Baptiste Onofré:
> Hi all,
>
> Users complained about the variable and long delays between Karaf
> releases. It's a fair comment and it's something that we have to improve.
>
> I propose the following new policy about the releases cycle:
> - for "active" branches (3.0.x and 2.4.x), I propose a release every 6
> weeks, with maximum extend to 8 weeks.
> - for "eol" and "maintenance" branches (2.2.x and 2.3.x), it's "on
> demand", no strong cycle there.
>
> WDYT ?
>
> If everybody agrees, I will update the releases schedule page on the
> website.
>
> Regards
> JB
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: [PROPOSAL] Karaf release cycle
Posted by Paul Spencer <pa...@apache.org>.
As a user of Karaf, I would appreciate release cycle like the one you describe.
As a developer, this can complicate the development process because one may need to hold commits until required dependency is released. Or said another way, commits requiring an unreleased dependency are not allowed. So please make sure procedures and guidelines are in place for your committers that support the release cycle without stifling the development process.
Paul Spencer
On Oct 8, 2014, at 1:52 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi all,
>
> Users complained about the variable and long delays between Karaf releases. It's a fair comment and it's something that we have to improve.
>
> I propose the following new policy about the releases cycle:
> - for "active" branches (3.0.x and 2.4.x), I propose a release every 6 weeks, with maximum extend to 8 weeks.
> - for "eol" and "maintenance" branches (2.2.x and 2.3.x), it's "on demand", no strong cycle there.
>
> WDYT ?
>
> If everybody agrees, I will update the releases schedule page on the website.
>
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: [PROPOSAL] Karaf release cycle
Posted by Paul Spencer <pa...@apache.org>.
As a user of Karaf, I would appreciate release cycle like the one you describe.
As a developer, this can complicate the development process because one may need to hold commits until required dependency is released. Or said another way, commits requiring an unreleased dependency are not allowed. So please make sure procedures and guidelines are in place for your committers that support the release cycle without stifling the development process.
Paul Spencer
On Oct 8, 2014, at 1:52 AM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi all,
>
> Users complained about the variable and long delays between Karaf releases. It's a fair comment and it's something that we have to improve.
>
> I propose the following new policy about the releases cycle:
> - for "active" branches (3.0.x and 2.4.x), I propose a release every 6 weeks, with maximum extend to 8 weeks.
> - for "eol" and "maintenance" branches (2.2.x and 2.3.x), it's "on demand", no strong cycle there.
>
> WDYT ?
>
> If everybody agrees, I will update the releases schedule page on the website.
>
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
Re: [PROPOSAL] Karaf release cycle
Posted by Matt Sicker <bo...@gmail.com>.
Personally, without a really easy way to upgrade Karaf in place, frequent
releases can become a bit of a pain. That, or better documentation on how
to use the karaf-maven-plugin would help a lot in that regard.
On 8 October 2014 00:58, Sobkowiak, Krzysztof <kr...@gmail.com>
wrote:
> +1 good idea
>
> Regards
> Krzysztof
>
> On 08.10.2014 07:52, Jean-Baptiste Onofré wrote:
> > Hi all,
> >
> > Users complained about the variable and long delays between Karaf
> > releases. It's a fair comment and it's something that we have to improve.
> >
> > I propose the following new policy about the releases cycle:
> > - for "active" branches (3.0.x and 2.4.x), I propose a release every 6
> > weeks, with maximum extend to 8 weeks.
> > - for "eol" and "maintenance" branches (2.2.x and 2.3.x), it's "on
> > demand", no strong cycle there.
> >
> > WDYT ?
> >
> > If everybody agrees, I will update the releases schedule page on the
> > website.
> >
> > Regards
> > JB
>
> --
> Krzysztof Sobkowiak
>
> JEE & OSS Architect | Technical Architect @ Capgemini | Committer @ ASF
> Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center
> <http://www.pl.capgemini-sdm.com/> | Wroclaw
> e-mail: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
> Twitter: @KSobkowiak
> Calendar: http://goo.gl/yvsebC
>
--
Matt Sicker <bo...@gmail.com>
Re: [PROPOSAL] Karaf release cycle
Posted by "Sobkowiak, Krzysztof" <kr...@gmail.com>.
+1 good idea
Regards
Krzysztof
On 08.10.2014 07:52, Jean-Baptiste Onofré wrote:
> Hi all,
>
> Users complained about the variable and long delays between Karaf
> releases. It's a fair comment and it's something that we have to improve.
>
> I propose the following new policy about the releases cycle:
> - for "active" branches (3.0.x and 2.4.x), I propose a release every 6
> weeks, with maximum extend to 8 weeks.
> - for "eol" and "maintenance" branches (2.2.x and 2.3.x), it's "on
> demand", no strong cycle there.
>
> WDYT ?
>
> If everybody agrees, I will update the releases schedule page on the
> website.
>
> Regards
> JB
--
Krzysztof Sobkowiak
JEE & OSS Architect | Technical Architect @ Capgemini | Committer @ ASF
Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center
<http://www.pl.capgemini-sdm.com/> | Wroclaw
e-mail: krzys.sobkowiak@gmail.com <ma...@gmail.com> |
Twitter: @KSobkowiak
Calendar: http://goo.gl/yvsebC