Stefano Bagnara wrote:
> IMHO you are describing a release numbering scheme that has never
> be used in past for James.
We've oft-debated what the next version number should be, and I think that we
might agree that at least some of our v2 versions should probably have become
v3, but we had envisioned keeping that for an even *more* major release.
What I described is, from memory, something that we have discussed when we've
tried to address versioning. Are you saying that you don't agree with the
idea, or what?
> As an example you deprecated fetchpop in 2.1 and added fetchmail in 2.2.
> You changed a FULL component in a minor point release without even using
> a deprecating step like I am proposing now.
Arguably, FetchPOP really didn't work well, and I do believe that we had both
in the system for quite some time, actually, so I'm not quite sure how you feel
that we did not deprecate it. And maybe we made a mistake.
In any event, you may find that I have been fairly consistent in asking that we
not "break" existing configurations so that administrators have as little work
as possible to do when upgrading JAMES, at least within a major release. And,
again, we've talked about whether or not we've made mistakes in release
numbering.
> If the way to work in peace is to name the current trunk 5.0
> I'm +1 to do so now ;-)
LOL. No, I hope not. For some things? Don't know. But I do think that you
are seeing what I mean. I have not asked that any of the things you want to do
not be done. I'm just suggesting that they don't all have the same timeframe
for release, and am trying to have a discussion about how we can get all of
those things, and more, done -- and still be able to release on a regular
basis, which we can all agree has not been done well in the past.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
