-
Notifications
You must be signed in to change notification settings - Fork 711
CSS Snapshot naming, transition requests, and always being a FIRST Public Note #6904
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I seem to remember suggesting the same thing at some point in the past, and someone (@fantasai I think) disagreeing. I am not sure I remember the reasons for that disagreement. |
We occasionally have updated a year's snapshot. They are separate publications, not just updates of the same publication. If we had standardized Previous Level links or something, we could use those to walk back years. That would be a useful for more specs than just the Snapshot also. |
I see them very much as updates of the same publication, as the /TR/CSS redirect clearly shows. What I propose would not, in any way, prevent us from updating a yearly snapshot. |
If we were to treat it as a single publication, could we still update the title every year to say “CSS Snapshot 20YY”? I don't believe there's any rule in the process against changing the title of a document, though I don't know about pub-rules. |
I think we could, as long as the shortname is the same (but I'm not sure if this document and CSS 1/2 are considered the same shortname). Many other specs that I'm involved in have changed their titles (but not shortnames) and were published without any trouble using echidna. |
Yes the title is separate from, and often more verbose than, the shortname. for example So I see no reason we could not have a shortname |
To me, yearly snapshots seem much more similar to different levels of the same CSS module, like css-cascade-3, css-cascade-4, ..., css-cascade-6. Each of them is a separate publication with a separate URL, they exist and evolve in parallel, and there is a "common" short url "css-cascade" (without the number) pointing to one of them (currently to level 4). What prevents the same naming/updating model from reusing for snapshots — with numbered versions for specific years' snapshots and just "https://www.w3.org/TR/css/" for the most current/actual one? |
/TR/CSS is a redirect to the current snapshot.
The actual snapshot is published as /TR/year/NOTE-css-year-fulldate whose latest version is /TR/css-year and is a First Public Note, which means it has no History and no previous version. Also we never publish another version. And we have to do a transition request each time, and can't use the automatic publishing system. (I tried, but failed)
If instead we published the snapshot as /TR/year/NOTE-css-fulldate with a latest version as /TR/css then in all subsequent years we would have a previous version /TR/lastyear/NOTE-css-lastyeardate which would mean we would only need to do a document transition once and in all subsequent years we would use the automatic publishing system.
Besides being easier and avoiding jumping through some publishing hoops, this would also be more accurate because it is indeed a set of revisions of basically the same document. It just has a yearly cadence. The entire point of the transition request for First anything is because it is a brand new thing.
The text was updated successfully, but these errors were encountered: