But I might miss the point why we have this intense discussion about naming "the next spec(s)" we are going to produce in the TOSCA TC.
Its just the pattern I'm used to. To me usually a major version number change implies BIG changes and that usually means breaking changes. Not a hard rule though. :-)
thanks
-Doug
________________________________________________________
STSM | Standards Architect | IBM Software Group
(919) 254-6905 | IBM 444-6905 | dug@us.ibm.com
The more I'm around some people, the more I like my dog.
<graycol.gif>"Probst, Richard" ---04/05/2013 07:23:10 PM---I am surprised to hear that calling something 'v2' implies incompatibility with v1. Is that common p
From:
"Probst, Richard" <richard.probst@sap.com>
To:
Doug Davis/Raleigh/IBM@IBMUS,
Cc:
"Lipton, Paul C" <Paul.Lipton@ca.com>, "tosca@lists.oasis-open.org" <tosca@lists.oasis-open.org>
Date:
04/05/2013 07:23 PM
Subject:
Re: [tosca] Starter Document for Topology and Orchestration Specification for Cloud Applications Version 2.0
I am surprised to hear that calling something 'v2' implies incompatibility with v1. Is that common practice in OASIS?
If so, I would definitely vote to call these docs v.next or v1.x, because we have not found any reason to be incompatible, and we don't want anyone to assume that we have.
But again, I'm surprised by this assumption.
Best,
--Richard
On Apr 5, 2013, at 2:21 PM, "Doug Davis" <dug@us.ibm.com> wrote:
I would actually prefer a version-less title because of the implications that including 'v2' in there will mean to people - mainly a set of breaking changes. Or maybe I'm reading too much into
presence of these docs all together and all we really care about is the new template and the editors will make the conversion using the existing v1 content. In which case its definitely not a v2 - it more like a v1.errata since there are no normative changes
- just an oasis template change. Was this discussed during the call? Sorry if I missed it.
Here's a possible scenario... we find that the current spec is basically ok as is - there might be some minor tweaks that can be dealt with in an errata but overall its fine. However, as you said, we need to define some concrete node types. I'm not convinced
that they would go into the current spec. They might go into a new document to highlight the separation of the tosca abstract notions from the concrete node types. That doesn't require a tosca v2. Or, perhaps we do stick it into the current doc but because
the existing features are untouched, its all non-backwards-breaking-changes, this again doesn't mean its a v2 it could be a v1.1.
The key thing to me is that v2 implies a set of breaking changes and we're not there yet and I don't feel comfortable assuming we'll have any. Rather than making a premature decision I'd prefer to see how things play out. I think its far more important that
we focus on interop testing of v1 and see where that leads us.
Let's discuss this on the next call.
thanks
-Doug
________________________________________________________
STSM | Standards Architect | IBM Software Group
(919) 254-6905 | IBM 444-6905 | dug@us.ibm.com
The more I'm around some people, the more I like my dog.
<graycol.gif>"Lipton, Paul C" ---04/05/2013 05:01:58 PM---Hi Doug, OASIS Staff requested that we start with fresh templates for the spec and the primer, in pa
From: "Lipton, Paul C" <Paul.Lipton@ca.com>
To: Doug Davis/Raleigh/IBM@IBMUS, "tosca@lists.oasis-open.org"
<tosca@lists.oasis-open.org>,
Date: 04/05/2013 05:01 PM
Subject: RE: [tosca] Starter Document for Topology and Orchestration Specification for Cloud Applications Version 2.0
Sent by: <tosca@lists.oasis-open.org>
Hi Doug,
OASIS Staff requested that we start with fresh templates for the spec and the primer, in part to make sure the format aligns with the latest OASIS format. We are required to provide a title and rather than opt for a version-less title or a confusing one, I
selected a title that was consistent with a version designation that the entire TC has been using freely. This is not necessarily a permanent title by any means.
I suggest we live with v2.0 as a proper, but “working title” for these working drafts, which have no real standing anyway, prior to the first Committee Spec Draft. As you say, we can have that discussion prior to CSD at which point we’ll certainly know if we
need to change the version.
That said; co-chair hat off now, I think our frequent, albeit perhaps subconscious use of the term v2 was telling. Just look at the lack of base classes in the current spec that we intend to specify, and the already present large volume of documents that have
been generated by the Interop SC. It seems extremely hard to believe that all of that constitutes an errata or v1.1, if we are to be honest with ourselves.
I hope that the situation and the lack of “title lock in” makes some sense to you and eases your concern.
Thanks,
Paul
From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
On Behalf Of Doug Davis
Sent: Friday, April 05, 2013 4:31 PM
To: tosca@lists.oasis-open.org
Subject: Re: [tosca] Starter Document for Topology and Orchestration Specification for Cloud Applications Version 2.0
tosca-chairs,
during the call on Thursday we talked a lot of v2 activities and perhaps I should have given the terminology more consideration (or I apologize if this was discussed during the call and I missed it) but I was interpreting the talks to really be about v.next
- meaning "whatever we do next". Whether that turns out to be a full v2, a v1.x or just an errata is yet to be seen. So, I was a bit surprised to see these "starter" documents get created with the assumption that we're immediately going to work on a v2.
I would prefer that we didn't make this assumption and waited until the TC made changes to our documents and _then_ we decided how best to release those - ie. as an errata, v1.x or v2. I think its too soon to jump to the v2 conclusion.
thanks
-Doug
________________________________________________________
STSM | Standards Architect | IBM Software Group
(919) 254-6905 | IBM 444-6905 | dug@us.ibm.com
The more I'm around some people, the more I like my dog.
<graycol.gif>Paul Knight ---04/05/2013 03:32:45 PM---Per the TC's submission request [1], please find the attached starter document for:
From: Paul Knight <paul.knight@oasis-open.org>
To: tosca@lists.oasis-open.org,
Date: 04/05/2013 03:32 PM
Subject: [tosca] Starter Document for Topology and Orchestration Specification for Cloud Applications Version 2.0
Sent by: <tosca@lists.oasis-open.org>
Per the TC's submission request [1], please find the attached starter document for:
Topology and Orchestration Specification for Cloud Applications Version 2.0
WP-abbrev: TOSCA
We expect this Work Product to be published at:
http://docs.oasis-open.org/tosca/TOSCA/v2.0/csd01/TOSCA-v2.0-csd01.doc
Please let me know if anything here fails to meet your expectations.
Further revisions to this Work Product must be maintained in Working Drafts, following procedures detailed in the OASIS TC Administration How-to Guide [2].
Working Drafts should be made available by uploading the document(s) to the TC's Kavi document repository, or (provisionally/temporarily) to the TC's Subversion (SVN) repository, if SVN has been activated for your TC [3]. TCs are encouraged to use ZIP packaging
when the WD releases contain multiple files (and directories).
For each WD revision, you will need to:
1) increment the Working Draft revision (number) from 01 to 02, 03, 04 etc., as successive Working Drafts are produced; the revision number needs to be updated at the top of the document in the stage identifier (Working Draft ##) and in the document identifier
within the page footer.
2) supply the relevant publication/release/upload date for each successive Working Draft instance, using the prescribed date format: DD Month YYYY; the date needs to be updated at the top of the document (just below the stage identifier, Working Draft ##)
and in the page footer.
3) provide suitable text for a document Abstract, updating this summary with successive revisions to provide an accurate description of the subject matter, goals, scope, etc.
4) keep the Acknowledgments (Appendix A) and Revision History (Appendix C) up-to-date with each WD revision.
5) consult the OASIS Naming Directives document when creating new artifacts that may be part of the Work Product (e.g., image files, XML schemas), observing the rules for name characters in files and proposed directories, and for proposed URIs/namespaces [4].
When the TC votes [5] to approve a Working Draft as a Committee Draft (CSD or CND), the Chair or other designated person must submit a "Committee Specification Draft Creation and Upload Request" accessible on the TC Administration Requests Page [6].
Upon receipt of this form, the TC Administrator will QC and process the Work Product for official publication in the OASIS Library (http://docs.oasis-open.org/) as a Committee Draft, including addition of the requisite
cover page metadata and other boilerplate information.
=========== References:
[1] https://tools.oasis-open.org/issues/browse/TCADMIN-1237
[2] Developing Committee Specifications and Notes
https://www.oasis-open.org/resources/tcadmin/developing-committee-specifications-and-notes
Starting a Working Draft
https://www.oasis-open.org/resources/tcadmin/starting-a-working-draft
[3] SVN Version control, via Tools
https://tools.oasis-open.org/
[4] OASIS Naming Directives
http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html
[5] Approval of a WD as a CD (CSD or CND)
https://www.oasis-open.org/resources/tcadmin/approving-a-committee-specification-or-note-draft
https://www.oasis-open.org/policies-guidelines/tc-process#committeeDraft
[6] TC Administration Requests Page, see Committee Specification Draft Creation / Upload Request
https://www.oasis-open.org/resources/tc-admin-requests
Best wishes,
Paul
--
Paul Knight - Tel: +1 781-861-1013
OASIS - Advancing open standards for the information society
Document Process Analyst
[attachment "TOSCA-v2.0-wd01.doc" deleted by Doug Davis/Raleigh/IBM]
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php <graycol.gif>