Re: Some thoughts on a new publication approach

On 23/10/2013 16:45 , Philippe Le Hegaret wrote:
> One point that I'm not sure you're addressing: the never-ending tension
> between the recommendations and the living specs, e.g. HTML 5.0 and HTML
> 5.1 for example. HTML 5.1 is for implementers: it contains the latest
> thinking and directions. We also like to have users looking at 5.1 for
> ideas and feedback. HTML 5.0 is for lawyers, product labeling, and for
> normative references. Users should also look at it to understand which
> features is more stable. There is always the possibility of pointing
> users only to HTML 5.1 and have marks in it to indicate which ones are
> part of HTML 5.0. Other variations are also possible (using caniuse for
> stable marks, etc.). It seems to me that more guidances to working
> groups and editors to address the tension would be helpful as part of
> the publication approach. CSS tries to address part of this by using
> shortnames (eg /TR/css-text and /TR/css-text-3) but that doesn't provide
> relief to the editors who have to maintain two editors' drafts.

Right. To put this differently, snapshots closer to the end of the 
Rec-track process may require a stabilisation branch, while the main 
draft keeps making progress into v.next.

I don't think that we should solve all the problems at once, and my idea 
with this new publication thing is that it would be flexible enough to 
accommodate a variety of more social solutions (i.e. we just pick the 
way in which we're organised) that can operate on top of it.

In practice, if your spec is of a manageable size, I think that the odds 
are that you won't need to maintain two branches, one for stability and 
one for development. At some point when implementations are getting 
pretty mature, it would likely be pretty natural for an editor to just 
work through the bugs and produce something that can be snapshotted, 
before moving on to newer things. But of course, for larger and more 
complex specs — of which HTML is the epitomising example — that's not an 
option.

I think that the most sensible approach for this would be:

   • /TR/shortname/ always points to the latest and greatest. For HTML, 
that would be the current master branch.
   • The editors can maintain a separate "stable" (or whatever) branch 
where they prepare the snapshots that will be used.
   • The draft can be exposed elsewhere if people need to review it (so 
long as it's not snapshotted though there ought to be little value; 
normally all the bugs fixed there should be fixed in master too).
   • If absolutely needed, we could expose an 
/in-stabilisation/shortname/ endpoint, but I don't think that's needed.

Does this make sense?

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Friday, 25 October 2013 11:06:18 UTC