Sounds all good.
Like Dan wrote some time ago we still can have bugfix releases for older
branches if someone steps in and does them.
That we as a community only maintain one stable branch with fixes sounds
good.
Christian
Am 25.06.2012 21:07, schrieb Jean-Baptiste Onofré:
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
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
