You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by no...@apache.org on 2006/06/09 14:44:34 UTC
svn commit: r413032 - in /james/server/trunk/src/java/org/apache/james:
smtpserver/AddHeaderHandler.java transport/mailets/AddHeader.java
Author: norman
Date: Fri Jun 9 05:44:34 2006
New Revision: 413032
URL: http://svn.apache.org/viewvc?rev=413032&view=rev
Log:
Remove the AddHeaderHandler and AddHeader from trunk cause these classes are marked as deprecated and replacements allready exists
Removed:
james/server/trunk/src/java/org/apache/james/smtpserver/AddHeaderHandler.java
james/server/trunk/src/java/org/apache/james/transport/mailets/AddHeader.java
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Release contents, nomenclature, and deprecation
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
> 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?
The only thing important to me is that we don't care about numbers while
we develop.
We put in the changes we need as soon as a committer have the time and
the will to create something new.
We try to keep the trunk code as stable as possible so to be able to
make a new release at any given point by just branching and starting
bugfixing.
We we decide to branch we know what is the feature set and what are the
changes against the previous version and we can *VOTE* for the revision
to branch and the number to use.
IMO we don't have enough developer power to block it because of a
roadmap including 2.3.1, 2.3.2, 2.4.0, 2.4.1, 2.5.0, 3.0, 4.0 and so on.
This would be a big mistake and I bet this would only bring James to
2.3.1 in an year and maybe 2.4.0 with few new features in 2 years.
So I would not like to put a label in our trunk. Trunk is trunk, is
where we, collaborating, put new code with not so specific order: only
branches should have a clear roadmap and todo list.
We already have outdated todos:
http://james.apache.org/todo.html
http://wiki.apache.org/james/JamesV3
We can achieve the goals only with new code: discussions and numbers,
unfortunately don't fix bugs and don't create new features.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: Release contents, nomenclature, and deprecation
Posted by "Noel J. Bergman" <no...@devtech.com>.
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Release contents, nomenclature, and deprecation
Posted by Stefano Bagnara <ap...@bago.org>.
IMHO you are describing a release numbering scheme that has never be
used in past for James. I don't think we should ever discuss about this now.
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.
That said I don't care of the number. If theway to work in peace is to
name the current trunk 5.0 I'm +1 to do so now ;-)
Stefano
Noel J. Bergman wrote:
> Stefano Bagnara wrote:
>
>> IMHO if we'll ever want to make a 2.3.x release then we will use the 2.3
>> branch, otherwise from trunk we should create a 2.4.0 or a 3.0.0.
>
> I'm not sure about trunk being v2.4 (as opposed to 3.0 - see below), but we'll see.
>
>> And about the removal: we deprecate them in 2.3 and we remove them in
>> 2.4. This makes sense to me, considering that we also have simple
>> substitutes for that.
>
> I would not deprecate until we come to a major release. Not 2.3.1 or 2.4, but a 3.0. We can call the releases whatever we want, but we have tried to stick with something like:
>
> X.Y.z: minor point release - bug fixes and minor enhancements
> X.y: minor release - bug fixes and compatible enhancements
> x: major release - major enhancements, and incompatible changes
>
> The proposed spooling changes would be a major release. Adding JMX, Derby, LDAP, would be a minor release. Fixing the key length when creating a new table would be the X.Y.z type of minor point release.
>
> Also, as undersirable as they might be, and even understanding that developers have done a lot of testing, I would be more expecting bugs in an X.0 release than in X.y or X.y.z. I would approach what we put into each release from that perspective, to ensure that our releases meet expectations for risk aversion.
>
> --- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Release contents, nomenclature, and deprecation
Posted by "Noel J. Bergman" <no...@devtech.com>.
Stefano Bagnara wrote:
> IMHO if we'll ever want to make a 2.3.x release then we will use the 2.3
> branch, otherwise from trunk we should create a 2.4.0 or a 3.0.0.
I'm not sure about trunk being v2.4 (as opposed to 3.0 - see below), but we'll see.
> And about the removal: we deprecate them in 2.3 and we remove them in
> 2.4. This makes sense to me, considering that we also have simple
> substitutes for that.
I would not deprecate until we come to a major release. Not 2.3.1 or 2.4, but a 3.0. We can call the releases whatever we want, but we have tried to stick with something like:
X.Y.z: minor point release - bug fixes and minor enhancements
X.y: minor release - bug fixes and compatible enhancements
x: major release - major enhancements, and incompatible changes
The proposed spooling changes would be a major release. Adding JMX, Derby, LDAP, would be a minor release. Fixing the key length when creating a new table would be the X.Y.z type of minor point release.
Also, as undersirable as they might be, and even understanding that developers have done a lot of testing, I would be more expecting bugs in an X.0 release than in X.y or X.y.z. I would approach what we put into each release from that perspective, to ensure that our releases meet expectations for risk aversion.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r413032 - in /james/server/trunk/src/java/org/apache/james:
smtpserver/AddHeaderHandler.java transport/mailets/AddHeader.java
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman wrote:
>> http://svn.apache.org/viewvc?rev=413032&view=rev
>
> Does this mean that 2.3 will be the last release that has them, and that releases later this summer will not? Or are we going to have to continue to use the 2.3 branch for an extended period of time?
>
> --- Noel
IMHO if we'll ever want to make a 2.3.x release then we will use the 2.3
branch, otherwise from trunk we should create a 2.4.0 or a 3.0.0.
And about the removal: we deprecate them in 2.3 and we remove them in
2.4. This makes sense to me, considering that we also have simple
substitutes for that.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: svn commit: r413032 - in
/james/server/trunk/src/java/org/apache/james:
smtpserver/AddHeaderHandler.java transport/mailets/AddHeader.java
Posted by Norman Maurer <nm...@byteaction.de>.
Am Freitag, den 09.06.2006, 20:41 +0200 schrieb Stefano Bagnara:
> Noel J. Bergman wrote:
> >> http://svn.apache.org/viewvc?rev=413032&view=rev
> >
> > Does this mean that 2.3 will be the last release that has them, and that releases later this summer will not? Or are we going to have to continue to use the 2.3 branch for an extended period of time?
> >
> > --- Noel
>
> IMHO if we'll ever want to make a 2.3.x release then we will use the 2.3
> branch, otherwise from trunk we should create a 2.4.0 or a 3.0.0.
>
> And about the removal: we deprecate them in 2.3 and we remove them in
> 2.4. This makes sense to me, considering that we also have simple
> substitutes for that.
>
> Stefano
What Stefano explains is exactly what i whould do.. This is why i mark
them in 2.3 as deprecated!
bye
Norman
RE: svn commit: r413032 - in /james/server/trunk/src/java/org/apache/james: smtpserver/AddHeaderHandler.java transport/mailets/AddHeader.java
Posted by "Noel J. Bergman" <no...@devtech.com>.
> http://svn.apache.org/viewvc?rev=413032&view=rev
Does this mean that 2.3 will be the last release that has them, and that releases later this summer will not? Or are we going to have to continue to use the 2.3 branch for an extended period of time?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org