Comments in-line below in response to comments from Bill Shannon and Hong.
vbk
Hong Zhang wrote:
> Bill Shannon wrote:
>>>> 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.
yes... but there is no reason to create a situation which makes it
easier to create (or may even necessitate) an incompatible change during
the release cycle, when it is drop dead simple to avoid it...
>>
>> 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?
And developers creating dev tests and qa folks creating functional and
system tests and early adopters/evanglists creating demos and...
There are many folks that have legitimate use-cases that precede the
general availability of GlassFish Server 3.1 that I want the dev builds
of NetBeans have 'supported' in the past
>> If you need to use the new DTDs, expect them to change until the code is
>> frozen.
I expect them to change. Early adopters expect them to change.... But
we do not need to set-up a situation where they should change, when we
could have avoided the issue completely...
> 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.
>
Again... why do we want to go from non-existence to "1", instead of
"0"... None of the glassfish-FOO_X_Y-Z.dtd files existed in a previous
release...
In all the previous cases we have started with sun-FOO_X_Y-0.dtd and
then created a sun-FOO_X_Y-1.dtd when we added elements/attributes to
the grammar defined in sun-FOO_X_Y-0.dtd that has been released.
> Thanks,
>
> - Hong
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>