Heh. I wouldn't worry about it too much. Though email doesn't translate very
well in all instances I took away a feeling more or less that Howard was
asking "Has jesse or anyone else broken backwards compatibility in 4.1? "
with a menacing look ;)
Indeed I haven't.
The versioning scheme you suggested sounds very reasonable to me. I don't
know how it plays into how the other apache projects do it though. I know
there was some discussion about this a while back with the conclusion that
we should try and follow more traditional approaches to versioning.
(Specifically Tomcat versioning).
On 5/1/06, Brian K. Wallace <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I am not, nor would I suggest, that any release except (based both on
the commits and things you have said in e-mails) 5.0 is 'not' backward
compatible. When it reaches the "not backward compatible" stage, it
makes sense to bump the major revision number and nothing less.
My question was more in line with 4.1 - I know Jesse's been putting a
lot of work into it and my question was simply: Is it still going to be
backward compatible?
All that was in regard to moving forward with a more standard "api
driven" numbering scheme - where users know what to expect with each
release based simply on the number. With X.Y.Z, a change in Z is bug fix
only and backward compatible; a change in Y is new feature(s) and
backward compatible; and a change in X is "all bets are off as to
backward compatibility due to new features".
Again - don't think I was suggesting something's not compatible with the
previous release of its major revision number (4 isn't with 3, but all
4's are, and all 3's are - that I know of). This was just a "grounding"
attempt to make sure we're getting the releases out - with the ability
to assure users of what they're getting without them having to pour over
the documentation.
Brian
Howard Lewis Ship wrote:
> Up to and including release 4.0, Tapestry numbering was "marketting
> driven". Every release was no backwards compatible to the previous
> release, and the numbering was basd on marketing reasons, rather than
> API compatibility.
>
> To what degree are these new releases NOT backwards compatible with
> the previous release?
>
> On 5/1/06, Brian K. Wallace <[EMAIL PROTECTED]> wrote:
> I know I'm sounding like a broken record, but here goes...
>
> With what's going into 4.0.3 (and 3.0.5, but that doesn't appear to
> affect anything if we bump to 3.1) as far as new features that are
> backward compatible, wouldn't 4.0.3 be better suited as 4.1? This would
> make the current 4.1 better as 4.2? Are all the changes in the current
> 4.1 backward compatible? Or would 4.1 be better as 5.0 - making the
> current 5.0 better as 6.0?
>
> Not trying to mess with anyone's ideas, just trying to stay coherent in
> our releases and give users proper expectations of our releases.
>
> [and believe it or not, I don't post unless I think it affects more than
> just me]
>
> Thoughts? [does anyone care? ('care' to be meant in the spirit of
> "numbering's fine as is")]
>
> Brian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFEVnABaCoPKRow/gARAnmHAKDWIO/+WOPYj+KIYZraidIw3kFIbQCePr/w
voa0Dmunl7+YCzqXTS6WTrM=
=x8+J
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.
