I lean towards #2. If each domain spec starts at 1.0, the version numbers can reflect the maturity level of that domain.
From: Steve K Speicher <[email protected]> To: [email protected] Date: 01/10/2012 05:14 PM Subject: [oslc-core] OSLC specification version numbering guidance Sent by: [email protected] As new specifications are being developed (and possibly new working groups on the horizon), I wanted to get a basic policy in place regarding spec version numbers. Here are some alternatives: #1 Coordinate numbers across all domains Set guidance that a WG spec will match its version number with "nearest" Core version number that it is based off of. If there is a need for minor spec update before next major version number, using n.0 and then n.1. Take a concrete example, say a spec (Automation) starts now and is based on Core 2.0, it will be Automation 2.0. #2 Provide loose guidance, workgroups can start at 1.0 State that if it is truelly the first, then just call it such. Take example above, you'll have Automation 1.0 based on Core 2.0. #3 Say nothing I'm in favor #1, stating it as guidance and not a hard rule. Are there any concerns with this type of guidance? Does anyone have a recommendation other than #1? Thanks, Steve Speicher | IBM Rational Software | (919) 254-0645 _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
