[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cmis] Versions of the Specification and Planning... (v0.52 vs. v0.6)
...on the issue of planning. I just discovered that the "Fix Version/s" is actually very well used throughout the issues tracker. Am I reading this right that there are no more open issues for 0.52? http://tools.oasis-open.org/issues/browse/CMIS?report=com.atlassian.jira.plugin.system.project%3Aopenissues-panel I would like to apologize for any inconvenience... regards, david On Wed, Mar 11, 2009 at 8:33 AM, David Nuescheler <david@day.com> wrote: > Hi All, > > thanks to both Davids for their constructive response. > > I think it would be great to have a "preview folder" for specification > proposals... would those be equivalent to the "proposals" that we have, > or do we need a distinction between "preview" and "proposals". > > regards, > david > > On Tue, Mar 10, 2009 at 7:34 PM, <Choy_David@emc.com> wrote: >> Yes, as David Nuescheler pointed out, there is confusion on version >> number. >> Given our intended scope for release 1 and our aggressive straw-man >> schedule, the new version (with new verbiage and many bug-fixes) is >> getting close. Let us designate it v0.6. The next "major" version >> (v0.7?) will likely be the incorporation of any pending proposal >> accepted by the TC. >> >> David Caruana made a good point that a version should include all its >> parts. I like his idea of "previewing" individual parts, and designating >> them as such. >> >> David >> >> -----Original Message----- >> From: David Caruana [mailto:david.caruana@alfresco.com] >> Sent: Tuesday, March 10, 2009 11:08 AM >> To: David Nuescheler >> Cc: cmis@lists.oasis-open.org >> Subject: Re: [cmis] Versions of the Specification and Planning... (v0.52 >> vs. v0.6) >> >> I agree with David's sentiments, both on the great work on the spec, >> but also around misunderstanding the plan. >> >> Perhaps with a few tweaks we can clarify how new spec versions are >> released. I'd like to present the following ideas. >> >> There's already the straw-man schedule with planned spec updates. This >> seems a great place to also indicate the intended version number of >> spec update. >> >> The planned spec updates are followed by review time, so I think all >> parts of the spec must be updated and released simultaneously for >> planned updates. >> >> There may be occasions where it's useful to provide previews of >> planned updates. In this case, the spec version is marked >> appropriately e.g. v0.6 preview 1. Perhaps it's ok to release >> individual parts of the spec for preview purposes. >> >> Issue resolution planning could be tracked in JIRA. I believe there's >> a 'Fix Version' field to target a resolution at a particular version >> of the spec. >> >> Regards, >> Dave >> >> >> On 10 Mar 2009, at 11:26, David Nuescheler wrote: >> >>> Hi All, >>> >>> thanks for everybody's great work on the specification. >>> I think it is really encouraging to see the issues come in >>> at a steady pace... >>> >>> I think I may have misunderstood the current plan and >>> wanted to check if I missed something. I thought the plan >>> was to release a 0.52 at end of this month? >>> So I was a little surprised to see 0.6 being checked in... >>> >>> Since we (the TC members) need to assign resources to >>> read through the specification (implementing or reading) I think >>> it would be very helpful for our planning to have a bit >>> of an "update plan" on when next version of the specification >>> will be released and what issues are being worked on. >>> >>> I appreciate that the synchronization between >>> Al and Ethan probably works fine in terms of who works on >>> what when, so it would be great if you could share your plan of >>> action with rest of the TC. I think this would be as simple >>> as sharing what issues you are currently working on. >>> >>> (Of course it would be great if the resolutions [newly committed >>> verbiage to the specification] would be shared in the respective >>> issue, as soon as it is in the private draft version of the spec, >>> since this would enable much faster turn around times, in >>> re-opening issues...) >>> >>> Maybe other members of the TC can comment on this as well. >>> >>> Maybe I am completely off here, and I just missed the information >>> on that subject, in which case I would like to apologize... >>> >>> regards, >>> david >>> >>> -- >>> Visit: http://dev.day.com/ >>> >>> --------------------------------------------------------------------- >>> 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 >>> >> >> >> --------------------------------------------------------------------- >> 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 >> >> >> > > > > -- > Visit: http://dev.day.com/ > -- Visit: http://dev.day.com/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]