Vincenzo Gianferrari Pini wrote:
Yes, but we already used a different scheme for 2.1, 2.2 and 2.3.. so
why change it for 2.4?
Because IMHO it was wrong :-) .
Ok, What I'm trying to say that consistency helps understanding: if you
change the rules in the middle you don't help people.
And if you really have to change the rule for the next minor why don't
we change the yet-to-be-release 2.3?
I simply say that imho this discussion does not belong to a 2.4.
Anyway, I always said that I don't care about the number while
discussing, I just care about what we release and when. So we can even
talk about "the next release" and skip the number if this helps (we'll
vote the number just before the release).
2.x releases have been storage compatible in past, so I think we can
safely put in the 2.x scheme every future storage compatible release
and keep 3.0 for bigger steps, but mine is only a +1 vs +0, no vetoes
about this meaningless thing: we need code to make releases, not numbers.
Not only storage compatible, but also configuration compatible etc.
About numbering, it is like naming: helps in stating things.
And please breathe a second and take it easy before ironizing and
telling other people that they say meaningless things etc. You won't
convince anybody this way, you will only put them off.
This is not true: 2.x releases have been only storage compatible. I had
to upgrade config.xml for evey second-digit step from 2.0 to 2.1.* to
2.2.0 to current 2.3.0rc3.
I don't say that what you say is meaningless, I say that numbering is
meaningless in a roadmap: a roadmap should include features, maybe
dates, but numbers are simply labels used to understand each other.
So my proposal is to choose 2 names: one for the release you and Noel
are proposing and that will be a branch of 2.3.0 with a few features
from trunk to be released before the end of november and the other for
the release I and Norman want to work for and to be branched from trunk
at start of January 2007 and released in March 2007.
I removed the (unused) 2.4 tag from our JIRA and renamed the 3.0 tag to
"Trunk" so that we don't introduce much more confusion. We marked things
resolved against 3.0, it is better to say that we resolved them in trunk
so we can rename trunk to something else when we'll branch. My fantasy
is limited so I would define then "next-minor-release" and
"next-major-release" (and we could have a "next-greater-release" for
storage incompatibility and other major changes).
I think that you can create a new version in jira and call it
"next-minor" and make a list of things you want to merge back in this
release. I hope it is fine for you if I won't work on this branch and to
agree that this release should not block trunk development or the start
of the "next-major" release.
I'm not trying to convince anyone, and I'm simply trying to define
something that works for me. If you say something that I think is not
correct I tell you: this is the way I discuss. I think I worked much
more than most of other committers on the James code in the last year so
I think that you may not have the same visibility I had on some of the
code that has been included in trunk and 2.3 branch, and that's why I
write them here. Take into consideration that I will always read and try
to understand your point: this doesn't mean I change my ideas easily,
but I change them very often (only stupids never change idea).
It's more than one year that I write to this list, you should have
learned that my discussion are a little rude. Don't take it so hard.
So this is how I think 2.4 should be: useful things that deserve and
*can* be added to 2.3 in a short time frame, without too much work:
very first among others the new fastfail (*if* the "without too much
work" applies). "Time driven instead of feature driven" for minor
releases.
If we take everything we have in trunk now and compare with 2.3 I
think that fastfail is one of the few things that cannot be backported
as is. As I already wrote we have uncomplete code both in trunk and in
an unfinished handlerv2 branch, so it's unfair (imo) to think that
merging fastfail to 2.3 is less work or it is safer than releasing
current trunk.
I don't say that it can be backported as is. My hope (and I know that I
may be wrong) is that it can be backported with some work. And releasing
current trunk means releasing the *whole* current trunk.
I can only repeat my vision of the current trunk:
there are a lot of finished things applied to that tree, and only one
thing is for sure in-progress and still subject to design analysis. This
thing is the fastfail, that is one of the core components of "your"
"next-minor" release.
I simply think that with almost the same efforts needed to release
2.3+new improved fastfail (next-minor) we would release the "next-major"
because that one is one of the few things that still deserve much attention.
Btw I don't know the future and I can only tell you what I guess: as I
said I don't want/need to convince anyone if everyone agree that we can
work on this 2 versions as separated and indipendent branches.
The only thing that worry me is that I want to be sure that if you
release in hurry a new fastfail architecture in the "next-minor" we
still mark it as experimental so we can tune it in the next-major or in
the next-greater if needed. Nothing more than this from me.
Furthermore I want to let you know that the new fastfail stuff need
changes to configuration files and would no allow conditions (ii) and
(iv), so using your numbering scheme would not be suitable for 2.4.
My point is (without integralism) to be able to get 2.4, and have my
production system run doing the same things as before with no or at
least little effort (no or very little changes to configuration) and
then, when I'm confortable, start exploiting the new features by
changing the configuration files. By little effort I mean also the
ability to easily rollback if weird things happen. And you know that
going from 2.2 to 2.3 was not simple at all!
*If* those things turn out to be impossible, then obviously we will
follow your and Norman's roadmap :-) . But *if* it is feasible, as also
Noel thinks, this is my choice.
Yes, maybe this is feasible.
Btw if you include config.xml and assembly.xml in your rollback you can
do it anyway: you just need storage compatibility for this. The only
difference is that you have an increased entry level because you have at
least to create the new config.xml in order to use it.
As I said I think that a new interim release (next-minor) is a good
thing to james. I just wanted to put emphasys on the fact that I can't
work on it because I spent too much on 2.3 branch (and if you remember
at that time I said I wouldn't have worked much on the branch because I
had to work in trunk) and if I want to keep working on James in future I
must ensure that James keep up with the needs of my customers.
I still run heavily modified local branches and my main reason for being
a committer to james is reduce my costs to keep them updated by sharing
my work with the community: 2.3 has been a failure in my roadmap, I
simply can't put more efforts in a conservative release.
I only care that this will not become a delaying issue for the release
I want to work on (call it 2.4, 2.5, 3.0, TNG or reloaded, not
important now).
I agree. I see work always being done on trunk, and some backporting to
a 2.4 branch.
Ok!
To "wrap up", a final consideration: as a James user, I prefer to
have *soon* a *few* new and "safe" functionalities rather than to
wait a long time for a lot of new functionalities. But in the long
term I want James to evolve ambitiously.
Well, in the last year we at least produced a release, the year before
this one nothing happened.
As a james user I prefer to have a release, than nothing.
I don't expect our small developers community to be able to follow
strict roadmaps and that's why I proposed a time based roadmap. We had
a 2 years release cycle for the 2.2=>2.3 step (i've been involved only
in the second year). It took one year from 2.1.3 to 2.2. So I would be
happy enough if we can start producing a new release every six months:
this is four times better than with 2.3 and 2 times better than 2.2.
Stefano, since you came in you did a tremendous and enormous work, and
we all did appreciate it a lot, and we know that a very large part of
2.3 is your merit. But one year ago (after a regrettable delay) we were
going to come out with a ("smaller") 2.3, that we were then unable to
finalize also because of your "vulcanic" :-) activity. And I bet that
if a few months ago we didn't decide to converge after some arguments,
2.3 would still be "on the clouds".
Ok, but you should also understand that we probably wouldn't have 2.3
out if I never worked on trunk: for full months you see only "bago" in
the svn log (for statistic funs: starting from 7 aug 2005 to 9 may 2006
you can find more than 200 commits and more than 90% were mine).
At that time I always said: simply decide when to branch and I'll help
with bug fixes but not with the other release issues. I did much more
than this. I fixed our package build, updated the website, fixed the
licesing issues and so on... I don't know why you never understood that
it was a matter of branching. I simply didn't agree to stop working on
trunk to let the code consolidate itself.
The only release I expect to come out faster is an optional bugfixing
2.3.1 release that should be prepared and released *before* branching
the trunk for the following release (so we follow the rule to have
only trunk and another active branch).
You see that your numbering scheme uses the third digit for bugfixing
releases ;-) .
Yes, I agree on that :-)
I could also agree on your numbering for the second digit but I really
don't like the inconsistencies with previous releases. Imho there is no
worldwide rule for "numbering" so people have to understand the
per-project rules, but we should avoid confusions introduced by subtle
changes in internal rules (even if there were not rules and this only
have been the effect of fate).
I hope all this makes sense :-) .
Vincenzo
I see that we have different ideas on the roadmap (or only on the
numebers?), I hope we can at least agree on the 2 working groups so
that we don't have to loose time discussing a roadmap that maybe no
one will ever be able to implement.
Discussing is not losing time. I try to convince you and you try to
convince me. You must convince me (and I'm quite open to it) that what
my roadmap is not feasible ("no one will ever be able to implement") or
that yours is "better", whatever it means.
Some discussion is a need, some discussion is funny but superfluos, many
discussions are only a lost of time. I feel responsible for some of them
and I'm just trying to avoid this mistake in future.
So I'm trying to skip the "you convince me", "I convince you" step and I
would like to convince ourselves that we can try working on both things
and maybe we'll merge on a single roadmap in the near or remote future.
I don't think that this is a generally valid approach but this time we
are talking about few efforts and not overriding each other. I have to
admit that if Norman was on the "next-minor" boat and against the
"next-major" I would have thought much more before proposing to try
following both, but I learned to work very well with Norman while I have
much more "discussion" problems with the other PMC committers (I know
this is a limit of mine) so the "split" thing make sense to me. It seems
that everyone can work on what he thinks it's better: and opensource
world works better when the project goals matches personal goals.
Both efforts will be a good thing to James and even if I consider the
"next-minor" not so good in term of "effort vs features" and I believe
that in 2 months here is very difficult to do anything (it took weeks
for simple test builds) I think that you will want to prove me wrong and
I will have to work harder on trunk while you are busy on the next-minor ;-)
And about the numbers I leave to you to decide when to start a vote to
change the "next-minor" and "next-major" labels to something with
numbers in it. I can already tell that I won't put vetoes, but I believe
this stuff should be decided in a vote once it's clear what is included
in each branch.
One last thing: keep in mind that if you want to make next-minor
starting from 2.3 branch and merging few stuff you will have to
relicense the code as the release will be out after 1st november and we
didn't update src headers in 2.3.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
