"Tim Colson \(tcolson\)" <[EMAIL PROTECTED]> writes:
>> i like major.minor.patch
>+1
>For most packages, I tend to avoid x.x.0 and wait for x.x.1 or x.x.2
>before upgrading. (And if it's an Atlassian product, I tend to wait for
>x.x.4)
I do, too. However, we have such a long release cycles, that a three number
scheme doesn't make too much sense.
>> i like neat codebases, so the "deprecate in A, leave in B, remove in
>> C" sounds good to me.
>I'm not sure I understand correctly ... do they literally use A B & C
>versions, or do you mean
>"deprecate in 1.0, leave in 1.1, remove in 1.2"
>or
>"deprecate in 1.x, leave in 2.x, remove in 3.x" ?
For Turbine we did "Deprecate in 2.3, remove in 2.4". We did have
2.3.1 and (soon) 2.3.2, so we basically applied the schemes described
in the APR rules (with a few exceptions; we e.g. upgraded
commons-email to release version which broke a few minor things).
>> 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.
>+1
>If it ain't broke, and I don't need the new features, and there isn't a
>"critical" fix/update/improvement in the old lib then it may stay at 1.x
>forever. ;-)
Yep.
Best regards
Henning
--
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 -- hero for hire
Linux, Java, perl, Solaris -- Consulting, Training, Development
4 - 8 - 15 - 16 - 23 - 42
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
