i like major.minor.patch i like neat codebases, so the "deprecate in A, leave in B, remove in C" sounds good to me.
as for "forcing people to rewrite", i don't think anyone is forcing them to use a new version. if they don't want to rewrite and their app is stable with an older version, they should not upgrade and risk instability. if their app is not running stable with an older version, they should upgrade, rewrite, and not rely on cruft hanging about as that might be part of their problem. still, i only like neat codebases. as long as it doesn't impede improvements, i don't mind a deprecated class hanging about. but if it's holding us back, then it's got to go. i also share Geir's aversion to "unnecessary dependencies". :) On 9/27/05, Will Glass-Husain <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
