Kev Jackson wrote:
Stefan Bodewig wrote:
Hi,
it's my strong belief that part of the reason the javah and move bugs
made it into 1.6.3 is that our branches are living too long. The same
happened to 1.5.2 (which required 1.5.3 quickly) because the 1.5
branch lived to long (IMHO).
In my day-to-day Ant usage I use CVS HEAD, all the time, exclusively.
Sometimes I merge changes into the 1.6 branch without merging the unit
tests as well. Sometimes I don't merge changes at all. Sometimes I
forget to pull a change from the branch when it has been pulled from
HEAD ...
If I read this correctly, you're saying that the number of bugs
increases when there's a long period of time between branches, mainly
because it's difficult to test the branch properly as most (if not all)
of the committers use HEAD. (sorry if that's pretty obvious, but I want
to be sure of what you're saying). It'd be interesting to see if other
open source projects experience the same situation.
This whole thing is an interesting problem.
You could argue that vendors like redhat and suse base much of their
business plan on providing stable versions of OSS projects, that is,
backporting bugs to stable OS releases, and effectively managing change
for their end users. When you subscribe to one of the distros what you
get is stability, not time-to-market features. That is free :)
Classic legacy shrink-wrapped apps have always charged for upgrades; in
exchange for a release "4.X", you get a period of time in which your
branch is the main app line, then a new release comes out, and it is
still maintained for a bit. All development of the 5.x line is secret
and not that relevant. As a vendor of such stuff, supporting old
versions is cost, but you cannot afford to give the users the 5.x branch
for free, as that upgrade revenue is your cash flow. We call this the
"old-microsoft-model", as they are the best at it. A problem they have
is separating people from their money, hence the current "only dinosaurs
run Office 97 ad series", which I personally think is wrong. (It's as if
volvo ran adds going "only dinosaurs run volvo tanks from the eighties.
They should be proud of the longevity of their product, not criticising
users happy with the old vehicles)
Real-time deployed services have no releases, have no branches, they
have "todays release" and "tomorrows release". This simplifies a lot.
Any defect can be fixed overnight, and WORKSFORME errors are almost
entirely eliminated. Against that a bad fix takes down your entire
infrastructure, and there is a lot of pressure to roll out priority
fixes immediately, without enough QA.
Ant originally released on almost a quarterly basis, with major changes
between them. Was it Ant1.2 that evaluated properties in the order they
were encountered at parse time, not execution time? Whatever, big
changes took place [1]. As it became more broadly used, we went to
annual releases, 1.3, 1.4, 1.5, with some bug fixes, but not much. All
the dev effort went primarily into the next release. And it made sense.
It was a small team, and there was no staff or need for old support.
Fast and frequent was it.
Ant1.5 probably marked the change, it was when ant went mainstream
-IDE integration
-books
-18-24 month interval between 1.5 and 1.6
Its also notable that Ant1.5.1 added a new feature, not a bug, a few
months after Ant1.5. Erik's <fileset file> feature, which is invaluable.
So we've been trickle feeding interesting stuff out for a while
Ant1.6.x was different again: major things have gone in to the point
releases. Nested conditions in fail, io redirectors, other stuff. All
excellent, all useful, and all major changes.
Some people were happy maintaining the branch (a lot of effort, I am
much more lazy and usually only commit to CVS_HEAD), and, and this is
important, the IDE users -netbeans, eclipse- seemed happy with point
releases too. Now that ant has moved on from being just a command line
tool, to something that most people first encounter in an IDE, it is one
step removed from end users. Our primary customers are now the IDE teams
[2], with their own wants and needs. One of those wants is releases on
their schedule, another is more soak-tested stability and IDE integration.
Question is, what was better: early point releases at the price of a
delayed Ant1.7? Especially given that a slow 1.7 release has let us be
relaxed about many things, discussing them, experimenting with them?
I think the branching has worked, to the extent that although we get
reports about problems fixed in CVS_HEAD, we dont get them about fixed
problems. The end users -via those IDEs- have recent copies of Ant.
Maybe we should have put
more bug fixes in, rather than less.
[1] I'll post a followup on that in a moment, having just looked through
my mail archives.
[2] this is like the retail channel is the primary customer for home
PCs, not the end user. And the PC vendors are the primary customer for
Windows OS releases. Its a complex little world out there.
Based on this...
+1 (my not quite 2p's worth)
My vote is aso: +1
I bet, other committers have similar experiences.
It's not enough to say users don't beta-test our releases, in all
honesty, after X.Y.1 or maybe X.Y.2 we don't even alpha-test them
sufficiently ourselves.
I think the gradual divergence has come to hurt us. Maybe we ought to
define a more formal policy for the future, such as annual releases,
point fixes every quarter, no more, no less. That way we offer
stability, and also get to head off pressure for more releases, putting
stuff into a branch update instead of the next major drop, etc, etc.
Rather we are busy testing the HEAD instead.
Also, when anyone files a bugrep we say "try against CVS_HEAD, close the
bug if it goes away"
-steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
