36 lines
2.4 KiB
Plaintext
36 lines
2.4 KiB
Plaintext
|
---+!! %TOPIC%
|
||
|
|
|
||
|
|
%META:TOPICINFO{author="BobMorris" date="1147861472" format="1.1" version="1.1"}%
|
||
|
|
%META:TOPICPARENT{name="SubversionReleaseProcedures"}%
|
||
|
|
An email exchange between Main.DamianBarnier and Main.BobMorris contained:
|
||
|
|
|
||
|
|
<verbatim>
|
||
|
|
Can you clarify what you mean by development, do you mean editing the
|
||
|
|
schema or creating instance documents, or both.
|
||
|
|
|
||
|
|
There may have been some confusion here, what I meant by 2. was should I
|
||
|
|
be exporting documents which validate against the released RC1 schema,
|
||
|
|
or the schema currently on the trunk.
|
||
|
|
|
||
|
|
</verbatim>
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
Certainly editing the schema should evolve only in the trunk. But:
|
||
|
|
|
||
|
|
a. Perhaps we should not call something a RC if there are known documents that didn't validate against it. In other words, if it still has known bugs.
|
||
|
|
|
||
|
|
b. Contrary to a., we could document the bugs in the RC known at release time.
|
||
|
|
|
||
|
|
c. Perhaps we develop a folder of standard documents that are supposed to validate, together with a text document that says which ones fail in the RC. [It begins to sound like we need a bug tracking server too...]. The document set could evolve from RC to RC, but would always do so in the trunk and the document set itself would evolve with the trunk and a snapshot of its state be part of the next RC
|
||
|
|
|
||
|
|
What I am after in the release procedure is this: Those people who take a release (in the generic sense, i.e. something in the releases/ tree and given a name) from the wiki or anywhere else should be guaranteed that what they take is never any different in any respect from what was given the RC designation. This scenario then arises:
|
||
|
|
|
||
|
|
Suppose we want to develop a portfolio of documents that illuminate the RC but this portfolio evolves _after_ the release. Indeed, that might be an admirable goal. That goal might even include documents that are valid and documents that are invalid. (The latter so that people can see what is problematic in an RC or Release). It wouldn't make sense to develop this in the trunk, as it is about something that is mainly about a particular RC or release. It may be that this should branch off the release so it can evolve on its own without some implication that that the \schema/ in the RC or release has changed.
|
||
|
|
|
||
|
|
Sooner or later we are going to face a similar issue about tools, and perhaps about a "contributed" subtree in which we place stuff not blessed by the committee but deemed useful.
|
||
|
|
|
||
|
|
I wonder if we need ReleaseUseCases
|
||
|
|
|
||
|
|
-- Main.BobMorris - 17 May 2006
|