>>> 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.
But if we want to encourage users to start using the new glassfish-*.dtd
and move away from the sun-*.dtd, the tools probably should use the
recommended set of the dtds? Also if there are new elements introduced
in 3.1, the tools want to make them available to the users too?
> If you need to use the new DTDs, expect them to change until the code is
> frozen.
Yes, agreed. There is always chance of them changing between now to code
freeze.
What about we use "-1" at the end for all the glassfish-*.dtd? The
contents could still change, but there will be less chance for
incompatible changes when adding new elements, and we could make things
a little easier for the tools.
Thanks,
- Hong