OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

chairs message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: Document numbering


Oh and do not forget that the documents also have a Version number that somehow has to be correlated to a CSD / CS version as well. Honestly, the way we do document versioning is just a mess and inconsistent TC to TC. So you could have:

Version 3.1.4 =ÂCS 02 = CSPRD = 03 = CSD 05 = WD 08


Thanks,
Bret
PGP Fingerprint:Â63B4 FC53 680A 6B7D 1447 ÂF2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."


On Mon, Oct 5, 2020 at 9:51 AM Bret Jordan <bret.jordan@broadcom.com> wrote:
Chet, et al.,Â

Please forward to the process committee.Â

As a board member I worked on trying to remove the working draft concept and have us just use CSDs. However, given that CSDs require some sort of formal approvalÂto release, aka a ballot, then we still have a problem. It comes from document numbering and being able to release documents on a routine basis.Â

Old System: (we understand the confusion and problems really well with this system)
WD 01
WD 02
WD 03
CSD 01
WD 04
WD 05
CSD 02
CSPRD 01
WD 06
CSD 03
WD 07
CSD 04
CSPRD 02
CS 01
WD 08
CSD 05
CSPRD 03
CS 02

So a TC only really reviews and works on working drafts. Yes, some only review CSDs, but that is not the majority of active people. So in this old model we have CS 02 = CSPRD = 03 = CSD 05 = WD 08. An utter mess.

With the new proposed model, there is no real semantic way of versioning the documents between approved releases of CSDs. So it makes it really difficult to keep track of what version you are working on. So much added complexity. About the best you can do is something like:

CSD 00.1
CSD 00.2
CSD 00.3
CSD 01.0 (approved release)
CSD 01.1 (should this minor version restart or should it continue like the WDs did)
CSD 01.2
CSD 02.0 (approved release)
CSD 02.1
CSD 03.0 (approved release)
CSPRD of CSD 03.0
CSD 03.1
CSD 04.0 (approved release)
CSPRD of CSD 04.0
CS 01
CSD 04.01
CSD 05.0
CSPRD of CSD 05.0
CS 02

SO CS 02 = CSD 05.0. This still seems a bit confusing. Maybe we do something like the following. This would keep a consistent semantic number scheme regardless of the delivery "stage".

CSD 0.0.1
CSD 0.0.2
CSD 0.0.3
CSD 0.1.0 (approved release)
CSD 0.1.1 (should this minor version restart or should it continue like the WDs did)
CSD 0.1.2
CSD 0.2.0 (approved release)
CSPRD of CSD 0.2.0
CSD 0.2.1
CSD 0.3.0 (approved release)
CSPRD of CSD 0.3.0
CSD 0.3.1
CSD 0.4.0 (approved release)
CSPRD of CSD 0.4.0
CS 1.0.0
CSD 1.0.1
CSD 1.1.0 (approved release)
CSPRD of CSD 1.1.0
CS 2.0.0

If we could get out of the notion of having CSDs be formally approved. Maybe the TC can have a standing rule that they can be released weekly or twice a month or when the Chairs and Editors find them to be in a good state. This would give us the following.Â

CSD 0.1
CSD 0.2
CSD 0.3
CSD 0.4
CSPRD of CSD 0.4
CSD 0.5
CSPRD of CSD 0.5.0
CSD 0.6
CSPRD of CSD 0.6
CS 1.0
CSD 1.1
CSPRD of CSD 1.1
CS 2.0

Obviously this is SO much easier and cleaner.Â

Thanks,
Bret
PGP Fingerprint:Â63B4 FC53 680A 6B7D 1447 ÂF2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]