Hi all,
we had the following result about the Karaf 2.1.x EOL and stop the 2.1.x
Jenkins:
+1 (binding): Andreas Pieber, Achim Nierbeck, Guillaume Nodet,
Jean-Baptiste Onofré, Christian Schneider, Freeman Fang, Charles Mouilliard
+1 (non-binding): Mike Van Geertruy, Johan Edstrom, Claus Ibsen
Thanks for the update Jamie.
I will send an e-mail to the user mailing list to inform the community.
Regards
JB
On 07/13/2011 12:50 PM, Jamie G. wrote:
It sounds like we have a consensus regarding option 1 and
de-allocating the jenkins profile for 2.1.x once we have 2.1.6
released.
I've creat
It sounds like we have a consensus regarding option 1 and
de-allocating the jenkins profile for 2.1.x once we have 2.1.6
released.
I've created a release task for 2.1.6 here:
https://issues.apache.org/jira/browse/KARAF-734
As discussed on the IRC chat room, we can always come back after the
state
Non binding and I too think EOL of 2.1 is okay. Its a bit fast though
for a project that is just 1 year old.
+1 for option 1.
There may be Camel and SMX users who are on Karaf 2.1. And they don't
migrate to new releases so often.
But I guess we can find out to help them if a critical issues is
di
+1 for option 1.
On Wed, Jul 13, 2011 at 3:22 AM, Johan Edstrom wrote:
> Non binding but I think EOL is great.
>
> +1 for option 1.
>
> /je
>
> On Jul 12, 2011, at 7:18 PM, Freeman Fang wrote:
>
>> +1 for option 1.
>>
>> Freeman
>> On 2011-7-13, at 上午2:30, Jamie G. wrote:
>>
>>> Hi All,
>>>
>>> A
Non binding but I think EOL is great.
+1 for option 1.
/je
On Jul 12, 2011, at 7:18 PM, Freeman Fang wrote:
> +1 for option 1.
>
> Freeman
> On 2011-7-13, at 上午2:30, Jamie G. wrote:
>
>> Hi All,
>>
>> As the 3.0.0 release draws near we'll be moving the 2.x branches to
>> maintenance mode. I
+1 for option 1.
Freeman
On 2011-7-13, at 上午2:30, Jamie G. wrote:
Hi All,
As the 3.0.0 release draws near we'll be moving the 2.x branches to
maintenance mode. I think as we do this we should consider the fate of
the last 2.1.x release version. Currently there are 5 resolved issued
in JIRA, wi
+1 for Option 1
Am 12.07.2011 20:30, schrieb Jamie G.:
Hi All,
As the 3.0.0 release draws near we'll be moving the 2.x branches to
maintenance mode. I think as we do this we should consider the fate of
the last 2.1.x release version. Currently there are 5 resolved issued
in JIRA, with no outstan
Hi Jamie,
1/ sounds good to me.
Regards
JB
On 07/12/2011 08:30 PM, Jamie G. wrote:
Hi All,
As the 3.0.0 release draws near we'll be moving the 2.x branches to
maintenance mode. I think as we do this we should consider the fate of
the last 2.1.x release version. Currently there are 5 resolved
Sounds good to me.
On Tue, Jul 12, 2011 at 22:49, Achim Nierbeck wrote:
> nothing else to say, Mike did a nice sum-up on it :-)
>
> +1 for option one
> +1 for de-allocating the Jenkins profile
>
> regards, Achim
>
>
> Am 12.07.2011 21:13, schrieb mikevan:
> > +1 to option one. That said, is anyt
nothing else to say, Mike did a nice sum-up on it :-)
+1 for option one
+1 for de-allocating the Jenkins profile
regards, Achim
Am 12.07.2011 21:13, schrieb mikevan:
> +1 to option one. That said, is anything ever really EOL? The reality is
> that if someone discovers a critical bug that keep
+1 to option one. That said, is anything ever really EOL? The reality is
that if someone discovers a critical bug that keeps 2.1.7 from working,
we'll have a hard time saying "Upgrade and go away". Its EOL, but with
limitations forced by reality.
+1 to de-allocating the Jenkins profile.
Andre
> 1) Release 2.1.6 and mark it in JIRA as the EOL (no entry for 2.1.7). Or,
Not so sure about this... You can never know if not somebody jumps up
and provides two critical bug-fixes for 2.1.x because he needs it. On
the other side: is there really and possibility that this happens? If
we remove 2.
Hi All,
As the 3.0.0 release draws near we'll be moving the 2.x branches to
maintenance mode. I think as we do this we should consider the fate of
the last 2.1.x release version. Currently there are 5 resolved issued
in JIRA, with no outstanding items on 2.1.6. I would like to propose
two options;
14 matches
Mail list logo
