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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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

Subject: Re: Next Version


| 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.


| 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.


| 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.


| 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.  :-)


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