Björn,
Yes, that is the plan, the current thinking is that n=2. That means that
we intend to actively support 2 past releases. It also means that a
given minor release will be supported for about a year. We didn't
formalize this, and it's not easy do to so, but that's the intent.
We are now in the process of doing major cleanup in preparation to the
camel-3.0 release, while staying backwards compatible as much as
possible with the 2.x versions. One of the intended consequences,
besides cleaning up the architecture, improving performance and
scalability and simplifying development is bringing down the build time.
This would go a long way towards making it possible to maintain older
branches, as build times right now are kinda prohibitive. We already
made major progress.
You are right about the bumpy road, and we are making major efforts to
smoothen it out.
Cheers,
Hadrian
On 09/09/2011 07:34 AM, Björn Bength wrote:
The definition of "as many versions as possible" must of course be decided.
But ought to be greater than 0 (zero).
Backporting and patch-releasing bug fixes are already done today by,
for instance, fusesource and yourself earlier.
To add value for their customers.
However, I think some attention on the Apache bug fix releases is, in
the longer run, necesseray.
Of course it requires resources, that often is busy full time with
their own customer's projects.
The full steam ahead on trunk has been impressive though, but it's
been a bumpy road :-)
regards
björn
On Fri, Sep 9, 2011 at 11:43 AM, Christian Schneider
<ch...@die-schneider.net> wrote:
Yes absolutely bug fix releases are key to stability and give us more
freedom to do changes in minor releases.
Until last year I was responsible for the internal camel and cxf
distributions at a germany energy company.
CXF could normally be used as is. If there were any bugs then typically the
next bugfix release had them fixed.
For camel I almost always had to maintain an internal bugfix release. As
camel only had minor versions every version contained the fixes but also a
lot of changes.
With these changes we often hist another issue again that prevented us from
rolling it out. So I ended up with taking the patches for the issues that
were important for us and
compiled my own bugfix release from the minor release we used. That worked
really well. As camel now supports bugfix releases I guess most times this
will not be necessary anymore for users.
I do not think backporting to as many versions as possible is a good idea
though. Typically having one or two maintained older version should be ok
for most occasions. That is because porting to older
versions is tpyically increasingly more work and every version to maintain
is generally a lot of additional work.
On the other hand we could have releases for older versions that are
requested by paying users of the companies that support camel development.
So this long term support could be a way for these companies to get support
contracts but still
having the results in the open as camel releases.
Christian
Am 09.09.2011 11:21, schrieb Björn Bength:
Hi,
This is one reason to have more "bug fix" releases like 2.5.1, 2.7.2,
2.8.1 etc
and make an effort to back port important bug fixes to as many
"stable" camel versions as possible.
Then I think slight api changes is more tolerable to end users.
Björn
--
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
