@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 > >
