Vince Kraemer wrote on 05/28/2010 04:16 PM:
>> What do you think about Bill's suggestion: Perhaps the "simply
>> renamed" ones should be "-0", and the "new content" ones should be "-1"?
>
> I am not thrilled by the idea.
>
> If we know, for 100% certain, that a dtd is just going to be renamed
> between now and the release date, then it would be acceptable to me...
> but I do not think we have that level of foreknowledge OR are will to be
> constrained to a rule that would require us to:
> a. NOT change the content of a dtd, or
> b. support all the various incarnations of the glassfish-FOO_X.Y-Z.dtd
> that appear between 'today' and the release.
>
> Here is my 'for instance'...
>
> Say we have a user (call him Larry) that creates a set of apps (or tests
> or whatever) that reference the glassfish-FOO_X.Y-0.dtd as we start to
> develop GlassFish Server 3.1.
>
> Later, a developer (lets call her Maureen) on the FOO module determines,
> "Uh-oh! I need to add an element/attribute/something to the grammar
> defined by the glassfish-FOO_X.Y-0.dtd" before 3.1 is final. No worries
> I will just put this new element in a new DTD called
> glassfish-FOO_X.Y-1.dtd.
>
> What does Maureen do about glassfish-FOO_X.Y-0.dtd?
>
> What do other teams do when they run into a reference to this 'between
> releases' version of the grammar for a glassfish-FOO.xml file?
>
> And what about Larry and his code...
>
> If Larry is developing tests, do we want to force him to do additional
> work on tests that are 'done'?
>
> If Larry is one of our early adopters, do we want to have him redo code
> that 'worked last week' to align it with a new name of a dtd... when the
> 'old name' was just as valid.
There's all kinds of things that can change incompatibly during the
process of designing and building the release. Developers should
expect that.
If they want stability, use a released final product, or at least use the
descriptors from a released final product.
Even if we pick the names for these DTDs now, and never change them for
the rest of this release, we're *still* not committing that each change
we make to the DTD will be completely upwards compatible with the previous
intermediate version of the DTD.
The tools, for instance, absolutely should not be generating descriptors
that match these new DTDs by default. Use the old DTDs, they still work.
If you need to use the new DTDs, expect them to change until the code is
frozen.