[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Next Version
[MCRAWFORD@lmi.org:] | Jon wrote: | | What do we think about calling the next release "UBL 2.0" | rather than "UBL 1.1" | | My comment - are we prepared to wait an additional 3-6 months to | do everything necessary for a major release? The suggestion is to take what we were going to release at the end of the year and call it "2.0" rather than "1.1". It could be argued that what we've agreed to do in implementing the (highly beneficial) submissions we're getting is going to be hard to accomplish in the time we've scheduled, but changing the name doesn't have much to do with this. The OASIS TC process does not distinguish between major revisions and minor revisions. The one difference the name change would make to our workload would be in allowing us to align with the noncontroversial aspects of the ATG NDRs earlier than we would otherwise be able to. While adopting the ATG CCT modules (for example) would entail some amount of work, I think we could limit the impact by simply declaring any change that looked like a lot of trouble to be out of scope for this release. [mark.palmer@nist.gov:] | As one who is working on building cooperation and convergence | between UBL and UN/CEFACT, changing the label for the next release | from 1.1 to 2.0, will add some confusion to the ongoing | discussions and the common understandings already established. Yes, it would require some explaining, but the people we're talking about seem to have already made the transition from "1.0" to "1.1" without serious injury. I would think they'd be happy to hear that this name change will allow us to reduce the number of differences between OASIS and UN/CEFACT NDRs earlier than forecast. It wouldn't resolve the big local/global issue, of course, but I doubt that anyone involved in the UN/UBL discussion would accept a solution associated with the number 2 but reject that same solution if associated with the number 3. The important thing as far as I'm concerned is that implementing the noncontroversial changes now while the installed base is still small will save our users a great deal of trouble going forward. [gkholman@CraneSoftwrights.com:] | 2.0 can certainly add to the set (I'm not advocating we not | increase the package), but 1.1 will give us a "more complete set" | than we had in 1.0, and may help to give the impression that we | are "finishing up" the first release. Then we can launch into a | 2.0. Don't kid yourself about the size of this beast. Implementing the joint European process model we requested will roughly double the size of the spec. I believe that this is the best thing that could possibly happen to both UBL and its users, but calling the result a minor revision doesn't really do justice to it. We're looking at a pretty big jump forward on the content side no matter what we do with the NDRs. [mhb@itst.dk:] | My comment - the process around a minor version release put | restrictions on the changes that could be done to the existing | messages. A major version release would have allowed for more | flexibility - meaning that the messages would not necessarily have | to be backwards compatible. The kind of changes we're talking about should cause relatively minor disruption compared to what we'll face later on if we wait another couple of years. Of course, people who've based their implementation on an older version might not care so much about this. :-) Jon
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]