Hi, The vote has passed with the following result :
+1 (binding): Jean-Baptiste Onofré, Ioannis Canellos, Freeman Fang, Guillaume Nodet, Achim Nierbeck, and Andreas Pieber. +1 (non binding): Romain Gilles, Ulhas Bhole, Christian Schneider, I will copy this release to the Karaf dist directory and promote the artifacts to the central Maven repository. Cheers, Jamie On Mon, Jun 25, 2012 at 4:37 PM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > Hi Christian, > > AFAIR, we discussed about that last year, when dealing about starting Karaf > 3.0.0 (I gonna looking for the thread in the archive). > > First we "decided" to have: > - one maintenance branch (bug fixes) aka 2.2.x > - one dev trunk aka 3.0.x > > 2.3.x should have been created after 3.0.0, but we decided to create it as a > transition between 2.2.x and 2.3.x. > > I will document that in a developer guide with the following table of > content: > - branches definition > - building > - style convention > - release guide > > If all are OK, I will start that in the plane tomorrow morning. > > Regards > JB > > > On 06/25/2012 08:53 PM, Christian Schneider wrote: >> >> Typically the number of parallel branches does not get too high anyway >> if we do not release that often. >> Still I think it makes sense to have at least an agreement to have for >> example 3 parallel branches like you proposed. >> So people know what to expect of us. >> >> Christian >> >> Am 25.06.2012 18:34, schrieb Andreas Pieber: >>> >>> @JB np, it's always quite a hard balance between bug/behavior change >>> >>> @christian: I wont see this that hard; we support the last minor >>> release and done; this makes three branches we actively work on (e.g. >>> 2.3.x, 2.4.x and 3.x). If ppl need longer support they need to buy it >>> from one of the supporters (talend, fuse, ...) or provide the fixes >>> themselves. We just need to keep the bar between minors as low as >>> possible to make the upgrade quite easy. Keeping a detailed upgrade >>> page will also help. But I think thats it. >>> >>> Kind regards, >>> Andreas >>> >>> On Mon, Jun 25, 2012 at 6:05 PM, Jean-Baptiste Onofré >>> <j...@nanthrax.net> wrote: >>>> >>>> I'm also agree. The change was not a new feature or an enhancement, >>>> it was a >>>> bug fix (as users reported). That's why I applied on 2.2.x branch, >>>> even if >>>> it was not very "clear". >>>> >>>> My apologies for that guys. >>>> >>>> Regards >>>> JB >>>> >>>> >>>> On 06/25/2012 03:49 PM, Andreas Pieber wrote: >>>>> >>>>> I'm the third one backing Guillaume here. I've a strong negative >>>>> feeling about changing behavior in micro releases if it's not a VERY >>>>> critical bug. PPL adapt to the behavior and will become "afraid" of >>>>> upgrading micro releases, although they definitely should do so to >>>>> become the latest bug-fixes and get the security holes stuffed. But, >>>>> since we've messed up this "concept" about 1k times for the 2.2.x >>>>> branch anyhow I don't consider it a show stopper now; nevertheless we >>>>> really should learn from this and do better for 2.3.x; I think this >>>>> also includes opening 2.4.x the moment 2.3.0 is released to make sure >>>>> that ppl have a place to include features/improvements and are not >>>>> tempted to include them into micros; but this is a different story :-) >>>>> >>>>> Independently I've tested the latest release (src builds, notice >>>>> checks, my applications, ...) and it looks really good to me. >>>>> >>>>> --> all in all +1 (binding) for the release. >>>>> >>>>> Kind regards, >>>>> Andreas >>>>> >>>>> On Mon, Jun 25, 2012 at 3:36 PM, Achim Nierbeck >>>>> <bcanh...@googlemail.com> >>>>> wrote: >>>>>> >>>>>> I second Guillaume here, we should be real careful not to add so much >>>>>> behavioral changes. >>>>>> >>>>>> regarding the release: +1 >>>>>> >>>>>> regards, Achim >>>>>> >>>>>> 2012/6/25 Guillaume Nodet <gno...@gmail.com>: >>>>>>> >>>>>>> Same feeling here, though I think we should learn from that and be >>>>>>> more vigilant about not introducing new features or behavioral >>>>>>> changes >>>>>>> in micro releases, that should have been done in 2.3. >>>>>>> >>>>>>> +1 >>>>>>> >>>>>>> On Sun, Jun 24, 2012 at 3:14 PM, Ioannis Canellos <ioca...@gmail.com> >>>>>>> wrote: >>>>>>>> >>>>>>>> Ideally, a micro release should guarantee forward and backward >>>>>>>> compatibility. >>>>>>>> >>>>>>>> I'd say though that the particular issue doesn't sound like a show >>>>>>>> stopper >>>>>>>> to me. >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> *Ioannis Canellos* >>>>>>>> * >>>>>>>> FuseSource <http://fusesource.com> >>>>>>>> >>>>>>>> ** >>>>>>>> Blog: http://iocanel.blogspot.com >>>>>>>> ** >>>>>>>> Twitter: iocanel >>>>>>>> * >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ------------------------ >>>>>>> Guillaume Nodet >>>>>>> ------------------------ >>>>>>> Blog: http://gnodet.blogspot.com/ >>>>>>> ------------------------ >>>>>>> FuseSource, Integration everywhere >>>>>>> http://fusesource.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/> >>>> >>>> >>>> -- >>>> Jean-Baptiste Onofré >>>> jbono...@apache.org >>>> http://blog.nanthrax.net >>>> Talend - http://www.talend.com >>>> >>>> >> >> > > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com > >
