Noel J. Bergman wrote:
Stefano Bagnara wrote:
But this time the problem is not only nomenclature, it is that you mixed
2.3.1 and next-minor. See bottom.
I was using 2.3.1 as a placeholder for next minor. Needed to call it
something in the properties file. Would have prefered to just call it 2.4.
I know. The property file is an issue for the current
next-minor/next-major schema.
If you ask me to number both next-minor and next-major now I would say:
2.4 for next-minor, 2.5 for next-major. Temporary numbers for the
property files. So we can keep using next-*. OK?
No, please! v2.3 branch is for 2.3.1 and we should backport there only
bugfixes. There is already need for the v2.3 branch to be separated by
the next-minor branch because the accept and unbounded cache fixes can
be included in v2.3 branch while the per service/per ip connection limit
can be only committed to the next-minor branch.
If you think that I am going to maintain fixes in several separate branches,
you are crazier than I am. :-)
Yeah, I'm crazier, for sure ;-) Was it a match?
I will help for 2.3.1 on the 2.3 branch and with next-major.
You can concentrate your efforts on next-minor so no "several separate
branches" for you.
I'll be happy to rename the v2.3 branch to
be the next minor branch, and copy the 2.3.0 tag back as the v2.3 branch for
you to maintain if that's your wish, but I've already been there, done that,
and have the T-shirt. Not going to happen again unless it has to happen,
and it doesn't. Perhaps you'll just to have to learn the same lessons about
release management that we learned the hard way.
I think we need both 2.3.1 (bugfixes only) and next-major.
I can be convinced that next-minor can replace 2.3.1, but you have to
give more details on next-minor, in the mean time leave the v2.3 branch
for 2.3.1 and create a new branch for next-minor.
Me, I'm planning to maintain a stable release branch and work on new things
in trunk.
"maintain a stable release branch" means "next-minor" ?
if this is true, and you can limit your trunk work to config.xml and
storage backward compatible changes until we'll branch next-major then
everything is ok, otherwise let's discuss a solution.
Maybe we decide not to release 2.3.1 and simply release "next-minor" as
2.4.0
That'd be my best guess.
Maybe.
We'll know this when you'll give us more details (I mean specific list
of features, and confirm the dates that are on the STATUS file) on
next-minor and 2.3.1 is the insurance in the mean time.
or maybe we decide to release a 2.3.1 in a month and release "next-major"
later if we decide not to release "next-minor".
I highly doubt it. Not unless "next-major" comes from the v2.3.0 codebase,
or a seriously stripped and vetted trunk.
--- Noel
*We* *are* *serious*, and we already vetted trunk in the last year: you
can doubt the fact that we are serious but this won't make us jokers.
Maybe you're simply fearing what you don't know: this often happens to
humans :-) .
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
