commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niall Pemberton <niall.pember...@gmail.com>
Subject Re: [SCXML] Next major version number required package rename needed?
Date Fri, 11 Oct 2013 00:40:45 GMT
I would bump to version 2.0 because I dont think its clear that going from
0.9 to 1.0 is a major version change - in my mind 0.9 seems to imply "we
haven't quite completed everything we want to for 1.0"

Niall


On Fri, Oct 11, 2013 at 12:52 AM, James Carman
<james@carmanconsulting.com>wrote:

> Now, this case is a bit weird, since we have released code in a < 1.0
> version number.  So, the artifact/package will have to be scxml1,
> which looks funky IMHO.  I guess that follows the pattern, though.
>
> On Thu, Oct 10, 2013 at 7:49 PM, Ate Douma <ate@douma.nu> wrote:
> > On 10/11/2013 01:41 AM, James Carman wrote:
> >>
> >> If you are breaking backward compatibility then you need to do the
> renames
> >> (package, and artifactId).
> >
> >
> > That was my impression already.
> > And I have no real issue with doing so.
> >
> > But again, when has this been decided and has it ever been formalized
> > (written down) somewhere?
> >
> >
> >>
> >> I don't know if we ever landed on a "rule" about the new JDK level
> >> scenario, though.
> >
> > Okay, maybe that was just an incorrect assumption.
> >
> > And it doesn't really matter as there will be breaking API changes needed
> > for the next version of SCXML, so we'll have to bump the major version
> > anyway.
> >
> >>
> >> On Thursday, October 10, 2013, Ate Douma wrote:
> >>
> >>> On 10/11/2013 01:16 AM, Emmanuel Bourg wrote:
> >>>
> >>>> Commons SCXML has only one reverse dependency in Maven Central,
> >>>> flexistate, so I wouldn't bother with the binary compatibility and
> just
> >>>> keep the package as is.
> >>>>
> >>>
> >>> Hmm. That might be the only reverse dependency of artifacts also
> deployed
> >>> to Maven Central, but I'm pretty sure SCXML 0.9 is used in plenty of
> >>> projects which might be impacted still.
> >>>
> >>> I would expect stronger arguments to decide yes/no if a package rename
> is
> >>> required or not. This would seem a bit (too) arbitrary to me.
> >>>
> >>> Mind you, I'd prefer not having to do a package rename, but I got the
> >>> impression there are more explicit 'rules' when to do so.
> >>>
> >>> So I'd still would like to hear more explicitly if such a rule is
> >>> defined,
> >>> and if so how it is worded and where. But of course if there is none,
> >>> fine
> >>> by me :)
> >>>
> >>> Thanks, Ate
> >>>
> >>>
> >>>>
> >>>> http://mvnrepository.com/**artifact/commons-scxml/**commons-scxml/0.9
> <http://mvnrepository.com/artifact/commons-scxml/commons-scxml/0.9>
> >>>>
> >>>> Emmanuel Bourg
> >>>>
> >>>>
> >>>>
> >>>>
> ------------------------------**------------------------------**---------
> >>>>
> >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>>>
> >>>
> >>>
> ------------------------------**------------------------------**---------
> >>>
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message