OK, I see the patch rule is based on the Talend customer.
On 7/6/11 9:32 PM, Daniel Kulp wrote:
One other note:
Talend has customers on 2.7.x that are not likely to move to 2.8.0 any time
soon. As Christian pointed out, lots of companies use a 6-8 month cycle,
Some longer, some shorter, and won't move off what they have for quite a bit
of time. Thus, no matter what, I am going to have to port some bug fixes
back to 2.7.x. There isn't anyway for me to avoid that (unless I tell my
customers "too bad, no fixes" which would not go over well :-) ). I COULD do
the porting on some private fork of the Camel branches and deliver the fixes
to the customers that way. That's definitely a perfectly valid way to do it.
In that case, all my work really would just benefit a small number of Camel
users. I'd MUCH MUCH prefer to do the porting here and allow my work to
benefit the entire Camel community. It's the exact same amount of work, just
in a different place. (well, I suppose if the fork is using git, it could be
a little less work as merging with git is so much nicer and faster, but still,
that's minor)
Likewise for releases. I could create private releases and stick them in a
"talend" repository someplace (and in some cases, I may need to do that
anyway), but I could also do roughly the same amount of work here (calling the
vote is additional work here, but that's minor) and the entire Camel user base
benefits. In addition, the releases here would go to central which makes our
customers happy. (no Nexus updates, firewall rules updates, etc...)
In short, the incremental cost for *ME* to continue supporting the fixes
branches that our customers are using is negligible. There's really no reason
to not do it. It has an additional benefit of making other Camel users
happier by providing more stable releases for them to use. IMO, it's
basically a "win-win" all around, or am I missing something?
Dan
On Wednesday, July 06, 2011 7:55:16 AM Christian Schneider wrote:
Hi Willem,
I can explain a bit from my experience as a user of Camel and CXF at my
former employer regarding patch releases.
We updated our stack every 6 to 8 months. With CXF this mostly simply
worked. When some bug was detected we could create an issue and help fix
it. It went into the next patch release and we could
update to this one instead of the feature release.
With Camel it was different. Every new release had a lot of new features
and changes. So we almost every time found a bug in the release that
prevented us to switch or that was a problem in production that needed
to be addressed. What went very well in Camel was reporting and fixing
bugs. I think Camel is probably the project I used where fixes to bugs
were made fastest. The problem was that the fix was only on trunk. Then
later it was incorporated into the new version. So my first strategy was
to update to the most current camel release when a bug was found and
fixed. The problem was that we almost every time found another problem
in the new release.
So what I did in the end was building our own release with the patches
to the bugs we had. This worked very well but not every customer wants
to do this.
Patch releases like 2.7.3 give the customer the fixes they need without
the breaking changes that cause new bugs. So from a customer standpoint
patch releases are very valueable. Of course they make life for us more
complicated so I think we should mostly only support one patch release
and one feature release at the same time. Of course a company like Fuse
or Talend can also do patch releases on their own but I think it is
better to have these releases at apache so it is transparent to the
customer what is in each release and he has no fear of vendor lock in.
Christian
Am 06.07.2011 04:09, schrieb Willem Jiang:
Hi Hadrian,
I think we are ready for the Camel 2.8.0 release.
But I'm not sure why you are still planing to do the patch release for
the 2.7.x as we never do this kind small patch release unless it
relates to a serious security issue before.
Can we just let the people move on to Camel 2.8.0 instead of confusing
about what's difference between the Camel 2.8.0 and Camel 2.7.3 ?
On 7/5/11 12:11 PM, Hadrian Zbarcea wrote:
Karaf 2.2.2 is now available and Willem did the upgrade. I think we
can
get ready to start the release. Are there any other issues that must
go
into 2.8.0?
I would also build a 2.7.3 at the same time, there are a few fixes and
improvements, including some around xmlsecurity.
Thoughts?
Hadrian
On 06/30/2011 11:07 PM, Willem Jiang wrote:
Hi,
I just applied the patch into trunk.
On 7/1/11 12:36 AM, Donald Whytock wrote:
https://issues.apache.org/jira/browse/CAMEL-3948
On Thu, Jun 30, 2011 at 12:35 PM, Donald
Whytock<dwhyt...@gmail.com>
wrote:
Just a reminder...CAMEL-3948 is marked as fixed, but the current
trunk
still needs my final patch.
Don
On Thu, Jun 30, 2011 at 2:46 AM, Jean-Baptiste
Onofré<j...@nanthrax.net> wrote:
Hi Claus,
Regarding Karaf 2.2.2, I've released OPS4J dependencies
yesterday.
Jamie
will cut off the release this afternoon.
Regards
JB
On 06/30/2011 08:31 AM, Claus Ibsen wrote:
Hi
Okay the JIRA roadmap for Camel 2.8 seems good now. There is
2 open
tickets.
- https://issues.apache.org/jira/browse/CAMEL-3774
- https://issues.apache.org/jira/browse/CAMEL-4144
CAMEL-3774 is about generating the manual and is assigned to
Hadrian.
CAMEL-4144 is about upgrading to Karaf 2.2.2. That release
is in
progress.
So by good chance we should be able to pickup that version
when its
released.
Alternatively we can stick to Karaf 2.2.1 which works fine.
(CAMEL-4144 is about some maven validate goal that would
require
Karaf
2.2.2 to pickup a fix in Karaf, but running Camel in Karaf
is
absolutely fine)
The CI servers also seems good. Although they tend to run
out of
memory at the end, such as when testing the examples. But
those are
the last piece of the build, and thus all components tests
fine.
I suggest that when Karaf 2.2.2 is out we git it a few spins
on
the CI
servers and then start cutting the Camel 2.8 release. Would
be
good to
get it out before the summer vacation starts. As well its
more
than 3
months since Camel 2.7 was released.
On Mon, Jun 27, 2011 at 9:35 AM, Claus
Ibsen<claus.ib...@gmail.com>
wrote:
Hi
Okay we should really start focusing on getting the last
tickets
which
has been assigned for 2.8 release done now.
There is about 350 tickets on the roadmap, so its going to
be the
biggest release, since 2.0 went GA.
So please take a look at your assigned tickets and get
them
done, or
move them for 2.9.
Then keep eyes on CI servers and help fix any test
failures, so we
have green builds.
The summer vacation period is approaching so we should
IMHO get
the
2.8 release out early next month if possible.
On Thu, Jun 9, 2011 at 2:47 PM, Hadrian
Zbarcea<hzbar...@gmail.com>
wrote:
Hi,
I would propose starting to close down and prepare for
the 2.8.0
release
in
2-3 weeks. There are already 282 issues for 2.8.0 and
chances are
will
be
over 300 by the release time, probably setting a new
record.
As of now there are 17 issues unresolved, a few of them
almost
done, so
by
next week I assume there'll be significantly less. I
would
suggest
shifting
the focus from adding new features to stabilizing the
build. If
there
are
any issues you know of that you think absolutely must be
in 2.8.0
please
shout and ask for help if needed (especially non
committers
subscribing
to
this list).
Thoughts?
Hadrian
--
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog: http://willemjiang.blogspot.com (English)
http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang
