Given how old this class is, I'm ok with removing it. But I'm equally okay
with letting any committer (Geir?) say keep it in.
It's 6 in the morning here - I'll read the article later. Might be useful
to write a Velocity versioning policy up and stick it on the Wiki with the
other dev info.
WILL
----- Original Message -----
From: "Geir Magnusson Jr." <[EMAIL PROTECTED]>
To: "Velocity Developers List" <[email protected]>
Sent: Tuesday, September 27, 2005 4:22 AM
Subject: Re: Versioning guidelines and ABI compability
On Sep 27, 2005, at 4:41 AM, Henning Schmiedehausen wrote:
Hi,
I didn't know about that page. I do like the idea of major.minor.patch,
but we haven't used three number versioning in the past so we would have
to start it for 1.5 (1.5.0?).
The alternative would be the old "Turbine deprecation rules", which work
pretty well for seldom released projects like Turbine or Velocity.
Deprecate after releasing Version "A", keep it deprecated in Version
"B", remove it in Version "C".
I always worry about removing deprecated things, as Velocity has been
very stable, and removing deprecated things forces people to rewrite.
Deprecation means "don't use this, and we won't maintain it..." IMO, and
"well remove at some point" is secondary.
There are some very broad (like all stuff in there) suggestions on how
to run deprecation at
http://maven.apache.org/development/deprecation.html (which is the
"Propaganda" link that is added to most Maven built sites because nobody
seems to know about the maven.xdoc.developmentProcessUrl property. :-)
I still would like to remove the Configuration stuff. It was intended as
a kludge until commons-collections came out with ExtendedProperties and
then scheduled to go away. This was ~ 4 years ago. And it would make it
very much easier to add commons-configuration based init code to
Velocity.
I'm not so sure. I personally am unnecessary-dependency-averse, and that
was a factor in the thinking. We needed one class..
Let's try lazy consensus here. If no one speaks up (this means you,
Will:-) ) and request re-adding of the Configuration class, I won't do
it.
Best regards
Henning
On Mon, 2005-09-26 at 23:55 -0700, Daniel Rall wrote:
On Mon, 26 Sep 2005, Henning P. Schmiedehausen wrote:
"Will Glass-Husain" <[EMAIL PROTECTED]> writes:
Hey -
That's a non backwards-compatible change.
Yes.
Where did we document this would happen in 1.3 or 1.4?
In the header of the class. It was deprecated in 1.1 and we kept it
deprecated in 1.2, 1.3, 1.3.1, 1.4. At some point we might want to let
go of the past. :-)
If anyone is actually using the Configuration class, they are probably
using Velocity 1.0 or so.
Speaking of which, I don't think we've ever formally adopted any
versioning
guidelines. APR has some good ones:
http://apr.apache.org/versioning.html
Given that Velocity is as much (or more) a library as an application,
it
would make sense to use the same (or very similar) guidelines.
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/
RedHat Certified Engineer -- Jakarta Turbine Development
Linux, Java, perl, Solaris -- Consulting, Training, Engineering
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
