Can the next release of the C++ broker and tools be 1.0.0?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Can the next release of the C++ broker and tools be 1.0.0?

Ken Giusti
Folks,

Given that we're able to release qpid-tools and qpidd broker independently for the API libraries, isn't it about time we bestow the honor of a 1.0.0 version to these packages?

These packages do not offer a "public API" as the libraries do, so technically semantic versioning rules don't apply. But those rules do define a major release of 0 (eg. 0.Y.Z) as being an "initial development release".  Furthermore, that's the common public perception of any software released with a 0.x.y version, IMHO.

For qpidd/tools - we're way, way beyond that.  qpidd/tools are mature to the point where existing functionality is stable.  If we were to deprecate features, we'd want to increment the X factor anyways, so at some point we really have to move beyond 0.x.y.

qpidd 1.0.0 shouldn't be in the same category as nuclear fusion or flying cars, right?

--
-K

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Can the next release of the C++ broker and tools be 1.0.0?

Robbie Gemmell
Administrator
On 5 November 2015 at 13:52, Ken Giusti <[hidden email]> wrote:

> Folks,
>
> Given that we're able to release qpid-tools and qpidd broker independently for the API libraries, isn't it about time we bestow the honor of a 1.0.0 version to these packages?
>
> These packages do not offer a "public API" as the libraries do, so technically semantic versioning rules don't apply. But those rules do define a major release of 0 (eg. 0.Y.Z) as being an "initial development release".  Furthermore, that's the common public perception of any software released with a 0.x.y version, IMHO.
>
> For qpidd/tools - we're way, way beyond that.  qpidd/tools are mature to the point where existing functionality is stable.  If we were to deprecate features, we'd want to increment the X factor anyways, so at some point we really have to move beyond 0.x.y.
>
> qpidd 1.0.0 shouldn't be in the same category as nuclear fusion or flying cars, right?
>
> --
> -K
>


Prior discussion on this (perhaps a year ago?) was that the qpid-cpp
version would indeed be changed, probably to something like 33.0 (at
the time), i.e move the dot[s] from prior release number cadence as a
starting point. The idea was also discussed to move the components to
their own source trees aligned on what would be released together
(independently of other bits), in this case having the cpp broker and
its tools in the same tree was proposed.

The proposed relocation work was done for the Java bits (initial
independent release with new version yet to happen, but is slated soon
as 6.0.0), and such alignment was implicit from the start for things
like proton/dispatch/jms. Nothing had changed in that regard for the
other components since those discussions, so when the most recent
qpid-cpp release was desired I simply continued with 0.34 from the
previous version scheme. I think it makes sense the first new version
should be used after such changes are made. I did create/rename a
bunch of separate versions in JIRA using '-next' versions in keeping
with desire to move them away from the previous versioing scheme in
future (and reflect the next release/version numbers not being decided
in all cases).

Robbie

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Can the next release of the C++ broker and tools be 1.0.0?

Ken Giusti
See inline:

----- Original Message -----

> From: "Robbie Gemmell" <[hidden email]>
> To: [hidden email]
> Sent: Thursday, November 5, 2015 9:22:07 AM
> Subject: Re: Can the next release of the C++ broker and tools be 1.0.0?
>
> On 5 November 2015 at 13:52, Ken Giusti <[hidden email]> wrote:
> > Folks,
> >
> > Given that we're able to release qpid-tools and qpidd broker independently
> > for the API libraries, isn't it about time we bestow the honor of a 1.0.0
> > version to these packages?
> >
> > These packages do not offer a "public API" as the libraries do, so
> > technically semantic versioning rules don't apply. But those rules do
> > define a major release of 0 (eg. 0.Y.Z) as being an "initial development
> > release".  Furthermore, that's the common public perception of any
> > software released with a 0.x.y version, IMHO.
> >
> > For qpidd/tools - we're way, way beyond that.  qpidd/tools are mature to
> > the point where existing functionality is stable.  If we were to deprecate
> > features, we'd want to increment the X factor anyways, so at some point we
> > really have to move beyond 0.x.y.
> >
> > qpidd 1.0.0 shouldn't be in the same category as nuclear fusion or flying
> > cars, right?
> >
> > --
> > -K
> >
>
>
> Prior discussion on this (perhaps a year ago?) was that the qpid-cpp
> version would indeed be changed, probably to something like 33.0 (at
> the time), i.e move the dot[s] from prior release number cadence as a
> starting point.

Ah, yes - I recall that also.  I've gotten that mixed up with the decision to use semantic versioning for proton + qpid-dispatch.


Personally, I'm not a fan of the N.x versioning approach, even when it comes to a standalone service like qpidd/tools (e.g. not a library).  As I mentioned above semantic versioning provides a bit more detail about the extent of changes in a given release.

So the first question I should've asked is:  Can we move qpidd/tools to semantic versioning?


> The idea was also discussed to move the components to
> their own source trees aligned on what would be released together
> (independently of other bits), in this case having the cpp broker and
> its tools in the same tree was proposed.
>
> The proposed relocation work was done for the Java bits (initial
> independent release with new version yet to happen, but is slated soon
> as 6.0.0), and such alignment was implicit from the start for things
> like proton/dispatch/jms. Nothing had changed in that regard for the
> other components since those discussions, so when the most recent
> qpid-cpp release was desired I simply continued with 0.34 from the
> previous version scheme. I think it makes sense the first new version
> should be used after such changes are made.


That makes sense to me - hold off any changes to the versioning semantics/format until after qpidd/tools are moved to their own source trees.


> I did create/rename a
> bunch of separate versions in JIRA using '-next' versions in keeping
> with desire to move them away from the previous versioing scheme in
> future (and reflect the next release/version numbers not being decided
> in all cases).
>
> Robbie
>

Thanks for the info Robbie.


> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

--
-K

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Can the next release of the C++ broker and tools be 1.0.0?

Robbie Gemmell
Administrator
On 9 November 2015 at 14:11, Ken Giusti <[hidden email]> wrote:

> See inline:
>
> ----- Original Message -----
>> From: "Robbie Gemmell" <[hidden email]>
>> To: [hidden email]
>> Sent: Thursday, November 5, 2015 9:22:07 AM
>> Subject: Re: Can the next release of the C++ broker and tools be 1.0.0?
>>
>> On 5 November 2015 at 13:52, Ken Giusti <[hidden email]> wrote:
>> > Folks,
>> >
>> > Given that we're able to release qpid-tools and qpidd broker independently
>> > for the API libraries, isn't it about time we bestow the honor of a 1.0.0
>> > version to these packages?
>> >
>> > These packages do not offer a "public API" as the libraries do, so
>> > technically semantic versioning rules don't apply. But those rules do
>> > define a major release of 0 (eg. 0.Y.Z) as being an "initial development
>> > release".  Furthermore, that's the common public perception of any
>> > software released with a 0.x.y version, IMHO.
>> >
>> > For qpidd/tools - we're way, way beyond that.  qpidd/tools are mature to
>> > the point where existing functionality is stable.  If we were to deprecate
>> > features, we'd want to increment the X factor anyways, so at some point we
>> > really have to move beyond 0.x.y.
>> >
>> > qpidd 1.0.0 shouldn't be in the same category as nuclear fusion or flying
>> > cars, right?
>> >
>> > --
>> > -K
>> >
>>
>>
>> Prior discussion on this (perhaps a year ago?) was that the qpid-cpp
>> version would indeed be changed, probably to something like 33.0 (at
>> the time), i.e move the dot[s] from prior release number cadence as a
>> starting point.
>
> Ah, yes - I recall that also.  I've gotten that mixed up with the decision to use semantic versioning for proton + qpid-dispatch.
>
>
> Personally, I'm not a fan of the N.x versioning approach, even when it comes to a standalone service like qpidd/tools (e.g. not a library).  As I mentioned above semantic versioning provides a bit more detail about the extent of changes in a given release.
>
> So the first question I should've asked is:  Can we move qpidd/tools to semantic versioning?
>

Sounds like a good idea to me.

>
>> The idea was also discussed to move the components to
>> their own source trees aligned on what would be released together
>> (independently of other bits), in this case having the cpp broker and
>> its tools in the same tree was proposed.
>>
>> The proposed relocation work was done for the Java bits (initial
>> independent release with new version yet to happen, but is slated soon
>> as 6.0.0), and such alignment was implicit from the start for things
>> like proton/dispatch/jms. Nothing had changed in that regard for the
>> other components since those discussions, so when the most recent
>> qpid-cpp release was desired I simply continued with 0.34 from the
>> previous version scheme. I think it makes sense the first new version
>> should be used after such changes are made.
>
>
> That makes sense to me - hold off any changes to the versioning semantics/format until after qpidd/tools are moved to their own source trees.
>
>
>> I did create/rename a
>> bunch of separate versions in JIRA using '-next' versions in keeping
>> with desire to move them away from the previous versioing scheme in
>> future (and reflect the next release/version numbers not being decided
>> in all cases).
>>
>> Robbie
>>
>
> Thanks for the info Robbie.
>
>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> --
> -K
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Can the next release of the C++ broker and tools be 1.0.0?

Chuck Rolke
It has been moved and seconded that the C++ broker and tools be 1.0.0. All in favor say 'aye'.

+1

----- Original Message -----

> From: "Robbie Gemmell" <[hidden email]>
> To: [hidden email]
> Sent: Monday, November 9, 2015 9:41:55 AM
> Subject: Re: Can the next release of the C++ broker and tools be 1.0.0?
>
> On 9 November 2015 at 14:11, Ken Giusti <[hidden email]> wrote:
> > See inline:
> >
> > ----- Original Message -----
> >> From: "Robbie Gemmell" <[hidden email]>
> >> To: [hidden email]
> >> Sent: Thursday, November 5, 2015 9:22:07 AM
> >> Subject: Re: Can the next release of the C++ broker and tools be 1.0.0?
> >>
> >> On 5 November 2015 at 13:52, Ken Giusti <[hidden email]> wrote:
> >> > Folks,
> >> >
> >> > Given that we're able to release qpid-tools and qpidd broker
> >> > independently
> >> > for the API libraries, isn't it about time we bestow the honor of a
> >> > 1.0.0
> >> > version to these packages?
> >> >
> >> > These packages do not offer a "public API" as the libraries do, so
> >> > technically semantic versioning rules don't apply. But those rules do
> >> > define a major release of 0 (eg. 0.Y.Z) as being an "initial development
> >> > release".  Furthermore, that's the common public perception of any
> >> > software released with a 0.x.y version, IMHO.
> >> >
> >> > For qpidd/tools - we're way, way beyond that.  qpidd/tools are mature to
> >> > the point where existing functionality is stable.  If we were to
> >> > deprecate
> >> > features, we'd want to increment the X factor anyways, so at some point
> >> > we
> >> > really have to move beyond 0.x.y.
> >> >
> >> > qpidd 1.0.0 shouldn't be in the same category as nuclear fusion or
> >> > flying
> >> > cars, right?
> >> >
> >> > --
> >> > -K
> >> >
> >>
> >>
> >> Prior discussion on this (perhaps a year ago?) was that the qpid-cpp
> >> version would indeed be changed, probably to something like 33.0 (at
> >> the time), i.e move the dot[s] from prior release number cadence as a
> >> starting point.
> >
> > Ah, yes - I recall that also.  I've gotten that mixed up with the decision
> > to use semantic versioning for proton + qpid-dispatch.
> >
> >
> > Personally, I'm not a fan of the N.x versioning approach, even when it
> > comes to a standalone service like qpidd/tools (e.g. not a library).  As I
> > mentioned above semantic versioning provides a bit more detail about the
> > extent of changes in a given release.
> >
> > So the first question I should've asked is:  Can we move qpidd/tools to
> > semantic versioning?
> >
>
> Sounds like a good idea to me.
>
> >
> >> The idea was also discussed to move the components to
> >> their own source trees aligned on what would be released together
> >> (independently of other bits), in this case having the cpp broker and
> >> its tools in the same tree was proposed.
> >>
> >> The proposed relocation work was done for the Java bits (initial
> >> independent release with new version yet to happen, but is slated soon
> >> as 6.0.0), and such alignment was implicit from the start for things
> >> like proton/dispatch/jms. Nothing had changed in that regard for the
> >> other components since those discussions, so when the most recent
> >> qpid-cpp release was desired I simply continued with 0.34 from the
> >> previous version scheme. I think it makes sense the first new version
> >> should be used after such changes are made.
> >
> >
> > That makes sense to me - hold off any changes to the versioning
> > semantics/format until after qpidd/tools are moved to their own source
> > trees.
> >
> >
> >> I did create/rename a
> >> bunch of separate versions in JIRA using '-next' versions in keeping
> >> with desire to move them away from the previous versioing scheme in
> >> future (and reflect the next release/version numbers not being decided
> >> in all cases).
> >>
> >> Robbie
> >>
> >
> > Thanks for the info Robbie.
> >
> >
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
> >>
> >>
> >
> > --
> > -K
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Can the next release of the C++ broker and tools be 1.0.0?

Steve Huston
+1

> -----Original Message-----
> From: Chuck Rolke [mailto:[hidden email]]
> Sent: Monday, November 09, 2015 1:15 PM
> To: [hidden email]
> Subject: Re: Can the next release of the C++ broker and tools be 1.0.0?
>
> It has been moved and seconded that the C++ broker and tools be 1.0.0. All
> in favor say 'aye'.
>
> +1
>
> ----- Original Message -----
> > From: "Robbie Gemmell" <[hidden email]>
> > To: [hidden email]
> > Sent: Monday, November 9, 2015 9:41:55 AM
> > Subject: Re: Can the next release of the C++ broker and tools be 1.0.0?
> >
> > On 9 November 2015 at 14:11, Ken Giusti <[hidden email]> wrote:
> > > See inline:
> > >
> > > ----- Original Message -----
> > >> From: "Robbie Gemmell" <[hidden email]>
> > >> To: [hidden email]
> > >> Sent: Thursday, November 5, 2015 9:22:07 AM
> > >> Subject: Re: Can the next release of the C++ broker and tools be 1.0.0?
> > >>
> > >> On 5 November 2015 at 13:52, Ken Giusti <[hidden email]> wrote:
> > >> > Folks,
> > >> >
> > >> > Given that we're able to release qpid-tools and qpidd broker
> > >> > independently for the API libraries, isn't it about time we
> > >> > bestow the honor of a
> > >> > 1.0.0
> > >> > version to these packages?
> > >> >
> > >> > These packages do not offer a "public API" as the libraries do,
> > >> > so technically semantic versioning rules don't apply. But those
> > >> > rules do define a major release of 0 (eg. 0.Y.Z) as being an
> > >> > "initial development release".  Furthermore, that's the common
> > >> > public perception of any software released with a 0.x.y version, IMHO.
> > >> >
> > >> > For qpidd/tools - we're way, way beyond that.  qpidd/tools are
> > >> > mature to the point where existing functionality is stable.  If
> > >> > we were to deprecate features, we'd want to increment the X
> > >> > factor anyways, so at some point we really have to move beyond
> > >> > 0.x.y.
> > >> >
> > >> > qpidd 1.0.0 shouldn't be in the same category as nuclear fusion
> > >> > or flying cars, right?
> > >> >
> > >> > --
> > >> > -K
> > >> >
> > >>
> > >>
> > >> Prior discussion on this (perhaps a year ago?) was that the
> > >> qpid-cpp version would indeed be changed, probably to something
> > >> like 33.0 (at the time), i.e move the dot[s] from prior release
> > >> number cadence as a starting point.
> > >
> > > Ah, yes - I recall that also.  I've gotten that mixed up with the
> > > decision to use semantic versioning for proton + qpid-dispatch.
> > >
> > >
> > > Personally, I'm not a fan of the N.x versioning approach, even when
> > > it comes to a standalone service like qpidd/tools (e.g. not a
> > > library).  As I mentioned above semantic versioning provides a bit
> > > more detail about the extent of changes in a given release.
> > >
> > > So the first question I should've asked is:  Can we move qpidd/tools
> > > to semantic versioning?
> > >
> >
> > Sounds like a good idea to me.
> >
> > >
> > >> The idea was also discussed to move the components to their own
> > >> source trees aligned on what would be released together
> > >> (independently of other bits), in this case having the cpp broker
> > >> and its tools in the same tree was proposed.
> > >>
> > >> The proposed relocation work was done for the Java bits (initial
> > >> independent release with new version yet to happen, but is slated
> > >> soon as 6.0.0), and such alignment was implicit from the start for
> > >> things like proton/dispatch/jms. Nothing had changed in that regard
> > >> for the other components since those discussions, so when the most
> > >> recent qpid-cpp release was desired I simply continued with 0.34
> > >> from the previous version scheme. I think it makes sense the first
> > >> new version should be used after such changes are made.
> > >
> > >
> > > That makes sense to me - hold off any changes to the versioning
> > > semantics/format until after qpidd/tools are moved to their own
> > > source trees.
> > >
> > >
> > >> I did create/rename a
> > >> bunch of separate versions in JIRA using '-next' versions in
> > >> keeping with desire to move them away from the previous versioing
> > >> scheme in future (and reflect the next release/version numbers not
> > >> being decided in all cases).
> > >>
> > >> Robbie
> > >>
> > >
> > > Thanks for the info Robbie.
> > >
> > >
> > >> -------------------------------------------------------------------
> > >> -- To unsubscribe, e-mail: [hidden email] For
> > >> additional commands, e-mail: [hidden email]
> > >>
> > >>
> > >
> > > --
> > > -K
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: [hidden email] For
> > > additional commands, e-mail: [hidden email]
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email] For additional
> > commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email] For additional
> commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Can the next release of the C++ broker and tools be 1.0.0?

Justin Ross-3
I'm late to this party.

What would you all say to 1.35.0?  I favor the .35. part in order to (1)
show the continuity with 0.34, and (2) suggest--correctly--that this is a
mature component.  I would consider this an optimization on top of the
above proposed move to 1.0.0, which I like.

Related notes:

 - Since for the foreseeable future the qpid::messaging API will remain in
the qpid-cpp tree, I have come to think that qpid-cpp is in effect a
library (among other things of course), and so deserves the major ("stable
interface") number.

 - As implied already, in order to be consistent with the other Qpid
components, I think we should go to simple increment-by-one versions.

Justin

On Mon, Nov 9, 2015 at 1:16 PM, Steve Huston <[hidden email]> wrote:

> +1
>
> > -----Original Message-----
> > From: Chuck Rolke [mailto:[hidden email]]
> > Sent: Monday, November 09, 2015 1:15 PM
> > To: [hidden email]
> > Subject: Re: Can the next release of the C++ broker and tools be 1.0.0?
> >
> > It has been moved and seconded that the C++ broker and tools be 1.0.0.
> All
> > in favor say 'aye'.
> >
> > +1
> >
> > ----- Original Message -----
> > > From: "Robbie Gemmell" <[hidden email]>
> > > To: [hidden email]
> > > Sent: Monday, November 9, 2015 9:41:55 AM
> > > Subject: Re: Can the next release of the C++ broker and tools be 1.0.0?
> > >
> > > On 9 November 2015 at 14:11, Ken Giusti <[hidden email]> wrote:
> > > > See inline:
> > > >
> > > > ----- Original Message -----
> > > >> From: "Robbie Gemmell" <[hidden email]>
> > > >> To: [hidden email]
> > > >> Sent: Thursday, November 5, 2015 9:22:07 AM
> > > >> Subject: Re: Can the next release of the C++ broker and tools be
> 1.0.0?
> > > >>
> > > >> On 5 November 2015 at 13:52, Ken Giusti <[hidden email]> wrote:
> > > >> > Folks,
> > > >> >
> > > >> > Given that we're able to release qpid-tools and qpidd broker
> > > >> > independently for the API libraries, isn't it about time we
> > > >> > bestow the honor of a
> > > >> > 1.0.0
> > > >> > version to these packages?
> > > >> >
> > > >> > These packages do not offer a "public API" as the libraries do,
> > > >> > so technically semantic versioning rules don't apply. But those
> > > >> > rules do define a major release of 0 (eg. 0.Y.Z) as being an
> > > >> > "initial development release".  Furthermore, that's the common
> > > >> > public perception of any software released with a 0.x.y version,
> IMHO.
> > > >> >
> > > >> > For qpidd/tools - we're way, way beyond that.  qpidd/tools are
> > > >> > mature to the point where existing functionality is stable.  If
> > > >> > we were to deprecate features, we'd want to increment the X
> > > >> > factor anyways, so at some point we really have to move beyond
> > > >> > 0.x.y.
> > > >> >
> > > >> > qpidd 1.0.0 shouldn't be in the same category as nuclear fusion
> > > >> > or flying cars, right?
> > > >> >
> > > >> > --
> > > >> > -K
> > > >> >
> > > >>
> > > >>
> > > >> Prior discussion on this (perhaps a year ago?) was that the
> > > >> qpid-cpp version would indeed be changed, probably to something
> > > >> like 33.0 (at the time), i.e move the dot[s] from prior release
> > > >> number cadence as a starting point.
> > > >
> > > > Ah, yes - I recall that also.  I've gotten that mixed up with the
> > > > decision to use semantic versioning for proton + qpid-dispatch.
> > > >
> > > >
> > > > Personally, I'm not a fan of the N.x versioning approach, even when
> > > > it comes to a standalone service like qpidd/tools (e.g. not a
> > > > library).  As I mentioned above semantic versioning provides a bit
> > > > more detail about the extent of changes in a given release.
> > > >
> > > > So the first question I should've asked is:  Can we move qpidd/tools
> > > > to semantic versioning?
> > > >
> > >
> > > Sounds like a good idea to me.
> > >
> > > >
> > > >> The idea was also discussed to move the components to their own
> > > >> source trees aligned on what would be released together
> > > >> (independently of other bits), in this case having the cpp broker
> > > >> and its tools in the same tree was proposed.
> > > >>
> > > >> The proposed relocation work was done for the Java bits (initial
> > > >> independent release with new version yet to happen, but is slated
> > > >> soon as 6.0.0), and such alignment was implicit from the start for
> > > >> things like proton/dispatch/jms. Nothing had changed in that regard
> > > >> for the other components since those discussions, so when the most
> > > >> recent qpid-cpp release was desired I simply continued with 0.34
> > > >> from the previous version scheme. I think it makes sense the first
> > > >> new version should be used after such changes are made.
> > > >
> > > >
> > > > That makes sense to me - hold off any changes to the versioning
> > > > semantics/format until after qpidd/tools are moved to their own
> > > > source trees.
> > > >
> > > >
> > > >> I did create/rename a
> > > >> bunch of separate versions in JIRA using '-next' versions in
> > > >> keeping with desire to move them away from the previous versioing
> > > >> scheme in future (and reflect the next release/version numbers not
> > > >> being decided in all cases).
> > > >>
> > > >> Robbie
> > > >>
> > > >
> > > > Thanks for the info Robbie.
> > > >
> > > >
> > > >> -------------------------------------------------------------------
> > > >> -- To unsubscribe, e-mail: [hidden email] For
> > > >> additional commands, e-mail: [hidden email]
> > > >>
> > > >>
> > > >
> > > > --
> > > > -K
> > > >
> > > > --------------------------------------------------------------------
> > > > - To unsubscribe, e-mail: [hidden email] For
> > > > additional commands, e-mail: [hidden email]
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email] For additional
> > > commands, e-mail: [hidden email]
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email] For additional
> > commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Can the next release of the C++ broker and tools be 1.0.0?

Robbie Gemmell
Administrator
In reply to this post by Chuck Rolke
I wouldnt say I said that exactly ;)

I don't actually mind too much what the version is, I mostly just had
dislike for the date based versions suggested previously. I'd say
there is an argument that had we ever changed from the 0.X versions to
1.0.0 at a more appropriate point previously then things would likely
be well beyond that now, and so having any new numbering account for
that somewhat wouldnt be the worst idea. That said, going back to the
start, I don't overly mind what the initial new numbers are, im more
interested in how they get used later.

Robbie

On 9 November 2015 at 18:14, Chuck Rolke <[hidden email]> wrote:

> It has been moved and seconded that the C++ broker and tools be 1.0.0. All in favor say 'aye'.
>
> +1
>
> ----- Original Message -----
>> From: "Robbie Gemmell" <[hidden email]>
>> To: [hidden email]
>> Sent: Monday, November 9, 2015 9:41:55 AM
>> Subject: Re: Can the next release of the C++ broker and tools be 1.0.0?
>>
>> On 9 November 2015 at 14:11, Ken Giusti <[hidden email]> wrote:
>> > See inline:
>> >
>> > ----- Original Message -----
>> >> From: "Robbie Gemmell" <[hidden email]>
>> >> To: [hidden email]
>> >> Sent: Thursday, November 5, 2015 9:22:07 AM
>> >> Subject: Re: Can the next release of the C++ broker and tools be 1.0.0?
>> >>
>> >> On 5 November 2015 at 13:52, Ken Giusti <[hidden email]> wrote:
>> >> > Folks,
>> >> >
>> >> > Given that we're able to release qpid-tools and qpidd broker
>> >> > independently
>> >> > for the API libraries, isn't it about time we bestow the honor of a
>> >> > 1.0.0
>> >> > version to these packages?
>> >> >
>> >> > These packages do not offer a "public API" as the libraries do, so
>> >> > technically semantic versioning rules don't apply. But those rules do
>> >> > define a major release of 0 (eg. 0.Y.Z) as being an "initial development
>> >> > release".  Furthermore, that's the common public perception of any
>> >> > software released with a 0.x.y version, IMHO.
>> >> >
>> >> > For qpidd/tools - we're way, way beyond that.  qpidd/tools are mature to
>> >> > the point where existing functionality is stable.  If we were to
>> >> > deprecate
>> >> > features, we'd want to increment the X factor anyways, so at some point
>> >> > we
>> >> > really have to move beyond 0.x.y.
>> >> >
>> >> > qpidd 1.0.0 shouldn't be in the same category as nuclear fusion or
>> >> > flying
>> >> > cars, right?
>> >> >
>> >> > --
>> >> > -K
>> >> >
>> >>
>> >>
>> >> Prior discussion on this (perhaps a year ago?) was that the qpid-cpp
>> >> version would indeed be changed, probably to something like 33.0 (at
>> >> the time), i.e move the dot[s] from prior release number cadence as a
>> >> starting point.
>> >
>> > Ah, yes - I recall that also.  I've gotten that mixed up with the decision
>> > to use semantic versioning for proton + qpid-dispatch.
>> >
>> >
>> > Personally, I'm not a fan of the N.x versioning approach, even when it
>> > comes to a standalone service like qpidd/tools (e.g. not a library).  As I
>> > mentioned above semantic versioning provides a bit more detail about the
>> > extent of changes in a given release.
>> >
>> > So the first question I should've asked is:  Can we move qpidd/tools to
>> > semantic versioning?
>> >
>>
>> Sounds like a good idea to me.
>>
>> >
>> >> The idea was also discussed to move the components to
>> >> their own source trees aligned on what would be released together
>> >> (independently of other bits), in this case having the cpp broker and
>> >> its tools in the same tree was proposed.
>> >>
>> >> The proposed relocation work was done for the Java bits (initial
>> >> independent release with new version yet to happen, but is slated soon
>> >> as 6.0.0), and such alignment was implicit from the start for things
>> >> like proton/dispatch/jms. Nothing had changed in that regard for the
>> >> other components since those discussions, so when the most recent
>> >> qpid-cpp release was desired I simply continued with 0.34 from the
>> >> previous version scheme. I think it makes sense the first new version
>> >> should be used after such changes are made.
>> >
>> >
>> > That makes sense to me - hold off any changes to the versioning
>> > semantics/format until after qpidd/tools are moved to their own source
>> > trees.
>> >
>> >
>> >> I did create/rename a
>> >> bunch of separate versions in JIRA using '-next' versions in keeping
>> >> with desire to move them away from the previous versioing scheme in
>> >> future (and reflect the next release/version numbers not being decided
>> >> in all cases).
>> >>
>> >> Robbie
>> >>
>> >
>> > Thanks for the info Robbie.
>> >
>> >
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: [hidden email]
>> >> For additional commands, e-mail: [hidden email]
>> >>
>> >>
>> >
>> > --
>> > -K
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]
>> > For additional commands, e-mail: [hidden email]
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Can the next release of the C++ broker and tools be 1.0.0?

Robbie Gemmell
Administrator
In reply to this post by Justin Ross-3
I'd say that seems preferable to 1.0.0 in some key ways as you
mention. It possibly still doesnt fully reflect the maturity thats
there already, but it would at least reflect it somewhat.

Robbie

On 9 November 2015 at 18:35, Justin Ross <[hidden email]> wrote:

> I'm late to this party.
>
> What would you all say to 1.35.0?  I favor the .35. part in order to (1)
> show the continuity with 0.34, and (2) suggest--correctly--that this is a
> mature component.  I would consider this an optimization on top of the
> above proposed move to 1.0.0, which I like.
>
> Related notes:
>
>  - Since for the foreseeable future the qpid::messaging API will remain in
> the qpid-cpp tree, I have come to think that qpid-cpp is in effect a
> library (among other things of course), and so deserves the major ("stable
> interface") number.
>
>  - As implied already, in order to be consistent with the other Qpid
> components, I think we should go to simple increment-by-one versions.
>
> Justin
>
> On Mon, Nov 9, 2015 at 1:16 PM, Steve Huston <[hidden email]> wrote:
>
>> +1
>>
>> > -----Original Message-----
>> > From: Chuck Rolke [mailto:[hidden email]]
>> > Sent: Monday, November 09, 2015 1:15 PM
>> > To: [hidden email]
>> > Subject: Re: Can the next release of the C++ broker and tools be 1.0.0?
>> >
>> > It has been moved and seconded that the C++ broker and tools be 1.0.0.
>> All
>> > in favor say 'aye'.
>> >
>> > +1
>> >
>> > ----- Original Message -----
>> > > From: "Robbie Gemmell" <[hidden email]>
>> > > To: [hidden email]
>> > > Sent: Monday, November 9, 2015 9:41:55 AM
>> > > Subject: Re: Can the next release of the C++ broker and tools be 1.0.0?
>> > >
>> > > On 9 November 2015 at 14:11, Ken Giusti <[hidden email]> wrote:
>> > > > See inline:
>> > > >
>> > > > ----- Original Message -----
>> > > >> From: "Robbie Gemmell" <[hidden email]>
>> > > >> To: [hidden email]
>> > > >> Sent: Thursday, November 5, 2015 9:22:07 AM
>> > > >> Subject: Re: Can the next release of the C++ broker and tools be
>> 1.0.0?
>> > > >>
>> > > >> On 5 November 2015 at 13:52, Ken Giusti <[hidden email]> wrote:
>> > > >> > Folks,
>> > > >> >
>> > > >> > Given that we're able to release qpid-tools and qpidd broker
>> > > >> > independently for the API libraries, isn't it about time we
>> > > >> > bestow the honor of a
>> > > >> > 1.0.0
>> > > >> > version to these packages?
>> > > >> >
>> > > >> > These packages do not offer a "public API" as the libraries do,
>> > > >> > so technically semantic versioning rules don't apply. But those
>> > > >> > rules do define a major release of 0 (eg. 0.Y.Z) as being an
>> > > >> > "initial development release".  Furthermore, that's the common
>> > > >> > public perception of any software released with a 0.x.y version,
>> IMHO.
>> > > >> >
>> > > >> > For qpidd/tools - we're way, way beyond that.  qpidd/tools are
>> > > >> > mature to the point where existing functionality is stable.  If
>> > > >> > we were to deprecate features, we'd want to increment the X
>> > > >> > factor anyways, so at some point we really have to move beyond
>> > > >> > 0.x.y.
>> > > >> >
>> > > >> > qpidd 1.0.0 shouldn't be in the same category as nuclear fusion
>> > > >> > or flying cars, right?
>> > > >> >
>> > > >> > --
>> > > >> > -K
>> > > >> >
>> > > >>
>> > > >>
>> > > >> Prior discussion on this (perhaps a year ago?) was that the
>> > > >> qpid-cpp version would indeed be changed, probably to something
>> > > >> like 33.0 (at the time), i.e move the dot[s] from prior release
>> > > >> number cadence as a starting point.
>> > > >
>> > > > Ah, yes - I recall that also.  I've gotten that mixed up with the
>> > > > decision to use semantic versioning for proton + qpid-dispatch.
>> > > >
>> > > >
>> > > > Personally, I'm not a fan of the N.x versioning approach, even when
>> > > > it comes to a standalone service like qpidd/tools (e.g. not a
>> > > > library).  As I mentioned above semantic versioning provides a bit
>> > > > more detail about the extent of changes in a given release.
>> > > >
>> > > > So the first question I should've asked is:  Can we move qpidd/tools
>> > > > to semantic versioning?
>> > > >
>> > >
>> > > Sounds like a good idea to me.
>> > >
>> > > >
>> > > >> The idea was also discussed to move the components to their own
>> > > >> source trees aligned on what would be released together
>> > > >> (independently of other bits), in this case having the cpp broker
>> > > >> and its tools in the same tree was proposed.
>> > > >>
>> > > >> The proposed relocation work was done for the Java bits (initial
>> > > >> independent release with new version yet to happen, but is slated
>> > > >> soon as 6.0.0), and such alignment was implicit from the start for
>> > > >> things like proton/dispatch/jms. Nothing had changed in that regard
>> > > >> for the other components since those discussions, so when the most
>> > > >> recent qpid-cpp release was desired I simply continued with 0.34
>> > > >> from the previous version scheme. I think it makes sense the first
>> > > >> new version should be used after such changes are made.
>> > > >
>> > > >
>> > > > That makes sense to me - hold off any changes to the versioning
>> > > > semantics/format until after qpidd/tools are moved to their own
>> > > > source trees.
>> > > >
>> > > >
>> > > >> I did create/rename a
>> > > >> bunch of separate versions in JIRA using '-next' versions in
>> > > >> keeping with desire to move them away from the previous versioing
>> > > >> scheme in future (and reflect the next release/version numbers not
>> > > >> being decided in all cases).
>> > > >>
>> > > >> Robbie
>> > > >>
>> > > >
>> > > > Thanks for the info Robbie.
>> > > >
>> > > >
>> > > >> -------------------------------------------------------------------
>> > > >> -- To unsubscribe, e-mail: [hidden email] For
>> > > >> additional commands, e-mail: [hidden email]
>> > > >>
>> > > >>
>> > > >
>> > > > --
>> > > > -K
>> > > >
>> > > > --------------------------------------------------------------------
>> > > > - To unsubscribe, e-mail: [hidden email] For
>> > > > additional commands, e-mail: [hidden email]
>> > > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: [hidden email] For additional
>> > > commands, e-mail: [hidden email]
>> > >
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email] For additional
>> > commands, e-mail: [hidden email]
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Can the next release of the C++ broker and tools be 1.0.0?

Timothy Bish
Agreed, having the additional version information beyond the 1.0.0
allows us to tell the story of where this came from and why it is indeed
a mature release.

On 11/09/2015 01:52 PM, Robbie Gemmell wrote:

> I'd say that seems preferable to 1.0.0 in some key ways as you
> mention. It possibly still doesnt fully reflect the maturity thats
> there already, but it would at least reflect it somewhat.
>
> Robbie
>
> On 9 November 2015 at 18:35, Justin Ross <[hidden email]> wrote:
>> I'm late to this party.
>>
>> What would you all say to 1.35.0?  I favor the .35. part in order to (1)
>> show the continuity with 0.34, and (2) suggest--correctly--that this is a
>> mature component.  I would consider this an optimization on top of the
>> above proposed move to 1.0.0, which I like.
>>
>> Related notes:
>>
>>  - Since for the foreseeable future the qpid::messaging API will remain in
>> the qpid-cpp tree, I have come to think that qpid-cpp is in effect a
>> library (among other things of course), and so deserves the major ("stable
>> interface") number.
>>
>>  - As implied already, in order to be consistent with the other Qpid
>> components, I think we should go to simple increment-by-one versions.
>>
>> Justin
>>
>> On Mon, Nov 9, 2015 at 1:16 PM, Steve Huston <[hidden email]> wrote:
>>
>>> +1
>>>
>>>> -----Original Message-----
>>>> From: Chuck Rolke [mailto:[hidden email]]
>>>> Sent: Monday, November 09, 2015 1:15 PM
>>>> To: [hidden email]
>>>> Subject: Re: Can the next release of the C++ broker and tools be 1.0.0?
>>>>
>>>> It has been moved and seconded that the C++ broker and tools be 1.0.0.
>>> All
>>>> in favor say 'aye'.
>>>>
>>>> +1
>>>>
>>>> ----- Original Message -----
>>>>> From: "Robbie Gemmell" <[hidden email]>
>>>>> To: [hidden email]
>>>>> Sent: Monday, November 9, 2015 9:41:55 AM
>>>>> Subject: Re: Can the next release of the C++ broker and tools be 1.0.0?
>>>>>
>>>>> On 9 November 2015 at 14:11, Ken Giusti <[hidden email]> wrote:
>>>>>> See inline:
>>>>>>
>>>>>> ----- Original Message -----
>>>>>>> From: "Robbie Gemmell" <[hidden email]>
>>>>>>> To: [hidden email]
>>>>>>> Sent: Thursday, November 5, 2015 9:22:07 AM
>>>>>>> Subject: Re: Can the next release of the C++ broker and tools be
>>> 1.0.0?
>>>>>>> On 5 November 2015 at 13:52, Ken Giusti <[hidden email]> wrote:
>>>>>>>> Folks,
>>>>>>>>
>>>>>>>> Given that we're able to release qpid-tools and qpidd broker
>>>>>>>> independently for the API libraries, isn't it about time we
>>>>>>>> bestow the honor of a
>>>>>>>> 1.0.0
>>>>>>>> version to these packages?
>>>>>>>>
>>>>>>>> These packages do not offer a "public API" as the libraries do,
>>>>>>>> so technically semantic versioning rules don't apply. But those
>>>>>>>> rules do define a major release of 0 (eg. 0.Y.Z) as being an
>>>>>>>> "initial development release".  Furthermore, that's the common
>>>>>>>> public perception of any software released with a 0.x.y version,
>>> IMHO.
>>>>>>>> For qpidd/tools - we're way, way beyond that.  qpidd/tools are
>>>>>>>> mature to the point where existing functionality is stable.  If
>>>>>>>> we were to deprecate features, we'd want to increment the X
>>>>>>>> factor anyways, so at some point we really have to move beyond
>>>>>>>> 0.x.y.
>>>>>>>>
>>>>>>>> qpidd 1.0.0 shouldn't be in the same category as nuclear fusion
>>>>>>>> or flying cars, right?
>>>>>>>>
>>>>>>>> --
>>>>>>>> -K
>>>>>>>>
>>>>>>>
>>>>>>> Prior discussion on this (perhaps a year ago?) was that the
>>>>>>> qpid-cpp version would indeed be changed, probably to something
>>>>>>> like 33.0 (at the time), i.e move the dot[s] from prior release
>>>>>>> number cadence as a starting point.
>>>>>> Ah, yes - I recall that also.  I've gotten that mixed up with the
>>>>>> decision to use semantic versioning for proton + qpid-dispatch.
>>>>>>
>>>>>>
>>>>>> Personally, I'm not a fan of the N.x versioning approach, even when
>>>>>> it comes to a standalone service like qpidd/tools (e.g. not a
>>>>>> library).  As I mentioned above semantic versioning provides a bit
>>>>>> more detail about the extent of changes in a given release.
>>>>>>
>>>>>> So the first question I should've asked is:  Can we move qpidd/tools
>>>>>> to semantic versioning?
>>>>>>
>>>>> Sounds like a good idea to me.
>>>>>
>>>>>>> The idea was also discussed to move the components to their own
>>>>>>> source trees aligned on what would be released together
>>>>>>> (independently of other bits), in this case having the cpp broker
>>>>>>> and its tools in the same tree was proposed.
>>>>>>>
>>>>>>> The proposed relocation work was done for the Java bits (initial
>>>>>>> independent release with new version yet to happen, but is slated
>>>>>>> soon as 6.0.0), and such alignment was implicit from the start for
>>>>>>> things like proton/dispatch/jms. Nothing had changed in that regard
>>>>>>> for the other components since those discussions, so when the most
>>>>>>> recent qpid-cpp release was desired I simply continued with 0.34
>>>>>>> from the previous version scheme. I think it makes sense the first
>>>>>>> new version should be used after such changes are made.
>>>>>>
>>>>>> That makes sense to me - hold off any changes to the versioning
>>>>>> semantics/format until after qpidd/tools are moved to their own
>>>>>> source trees.
>>>>>>
>>>>>>
>>>>>>> I did create/rename a
>>>>>>> bunch of separate versions in JIRA using '-next' versions in
>>>>>>> keeping with desire to move them away from the previous versioing
>>>>>>> scheme in future (and reflect the next release/version numbers not
>>>>>>> being decided in all cases).
>>>>>>>
>>>>>>> Robbie
>>>>>>>
>>>>>> Thanks for the info Robbie.
>>>>>>
>>>>>>
>>>>>>> -------------------------------------------------------------------
>>>>>>> -- To unsubscribe, e-mail: [hidden email] For
>>>>>>> additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> -K
>>>>>>
>>>>>> --------------------------------------------------------------------
>>>>>> - To unsubscribe, e-mail: [hidden email] For
>>>>>> additional commands, e-mail: [hidden email]
>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email] For additional
>>>>> commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email] For additional
>>>> commands, e-mail: [hidden email]
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Tim Bish
Sr Software Engineer | RedHat Inc.
[hidden email] | www.redhat.com
twitter: @tabish121
blog: http://timbish.blogspot.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Can the next release of the C++ broker and tools be 1.0.0?

Ken Giusti
In reply to this post by Justin Ross-3


----- Original Message -----

> From: "Justin Ross" <[hidden email]>
> To: [hidden email]
> Sent: Monday, November 9, 2015 1:35:07 PM
> Subject: Re: Can the next release of the C++ broker and tools be 1.0.0?
>
> I'm late to this party.
>
> What would you all say to 1.35.0?  I favor the .35. part in order to (1)
> show the continuity with 0.34, and (2) suggest--correctly--that this is a
> mature component.  I would consider this an optimization on top of the
> above proposed move to 1.0.0, which I like.

+1 to 1.35.0


>
> Related notes:
>
>  - Since for the foreseeable future the qpid::messaging API will remain in
> the qpid-cpp tree, I have come to think that qpid-cpp is in effect a
> library (among other things of course), and so deserves the major ("stable
> interface") number.
>
>  - As implied already, in order to be consistent with the other Qpid
> components, I think we should go to simple increment-by-one versions.
>
> Justin
>
> On Mon, Nov 9, 2015 at 1:16 PM, Steve Huston <[hidden email]> wrote:
>
> > +1
> >
> > > -----Original Message-----
> > > From: Chuck Rolke [mailto:[hidden email]]
> > > Sent: Monday, November 09, 2015 1:15 PM
> > > To: [hidden email]
> > > Subject: Re: Can the next release of the C++ broker and tools be 1.0.0?
> > >
> > > It has been moved and seconded that the C++ broker and tools be 1.0.0.
> > All
> > > in favor say 'aye'.
> > >
> > > +1
> > >
> > > ----- Original Message -----
> > > > From: "Robbie Gemmell" <[hidden email]>
> > > > To: [hidden email]
> > > > Sent: Monday, November 9, 2015 9:41:55 AM
> > > > Subject: Re: Can the next release of the C++ broker and tools be 1.0.0?
> > > >
> > > > On 9 November 2015 at 14:11, Ken Giusti <[hidden email]> wrote:
> > > > > See inline:
> > > > >
> > > > > ----- Original Message -----
> > > > >> From: "Robbie Gemmell" <[hidden email]>
> > > > >> To: [hidden email]
> > > > >> Sent: Thursday, November 5, 2015 9:22:07 AM
> > > > >> Subject: Re: Can the next release of the C++ broker and tools be
> > 1.0.0?
> > > > >>
> > > > >> On 5 November 2015 at 13:52, Ken Giusti <[hidden email]> wrote:
> > > > >> > Folks,
> > > > >> >
> > > > >> > Given that we're able to release qpid-tools and qpidd broker
> > > > >> > independently for the API libraries, isn't it about time we
> > > > >> > bestow the honor of a
> > > > >> > 1.0.0
> > > > >> > version to these packages?
> > > > >> >
> > > > >> > These packages do not offer a "public API" as the libraries do,
> > > > >> > so technically semantic versioning rules don't apply. But those
> > > > >> > rules do define a major release of 0 (eg. 0.Y.Z) as being an
> > > > >> > "initial development release".  Furthermore, that's the common
> > > > >> > public perception of any software released with a 0.x.y version,
> > IMHO.
> > > > >> >
> > > > >> > For qpidd/tools - we're way, way beyond that.  qpidd/tools are
> > > > >> > mature to the point where existing functionality is stable.  If
> > > > >> > we were to deprecate features, we'd want to increment the X
> > > > >> > factor anyways, so at some point we really have to move beyond
> > > > >> > 0.x.y.
> > > > >> >
> > > > >> > qpidd 1.0.0 shouldn't be in the same category as nuclear fusion
> > > > >> > or flying cars, right?
> > > > >> >
> > > > >> > --
> > > > >> > -K
> > > > >> >
> > > > >>
> > > > >>
> > > > >> Prior discussion on this (perhaps a year ago?) was that the
> > > > >> qpid-cpp version would indeed be changed, probably to something
> > > > >> like 33.0 (at the time), i.e move the dot[s] from prior release
> > > > >> number cadence as a starting point.
> > > > >
> > > > > Ah, yes - I recall that also.  I've gotten that mixed up with the
> > > > > decision to use semantic versioning for proton + qpid-dispatch.
> > > > >
> > > > >
> > > > > Personally, I'm not a fan of the N.x versioning approach, even when
> > > > > it comes to a standalone service like qpidd/tools (e.g. not a
> > > > > library).  As I mentioned above semantic versioning provides a bit
> > > > > more detail about the extent of changes in a given release.
> > > > >
> > > > > So the first question I should've asked is:  Can we move qpidd/tools
> > > > > to semantic versioning?
> > > > >
> > > >
> > > > Sounds like a good idea to me.
> > > >
> > > > >
> > > > >> The idea was also discussed to move the components to their own
> > > > >> source trees aligned on what would be released together
> > > > >> (independently of other bits), in this case having the cpp broker
> > > > >> and its tools in the same tree was proposed.
> > > > >>
> > > > >> The proposed relocation work was done for the Java bits (initial
> > > > >> independent release with new version yet to happen, but is slated
> > > > >> soon as 6.0.0), and such alignment was implicit from the start for
> > > > >> things like proton/dispatch/jms. Nothing had changed in that regard
> > > > >> for the other components since those discussions, so when the most
> > > > >> recent qpid-cpp release was desired I simply continued with 0.34
> > > > >> from the previous version scheme. I think it makes sense the first
> > > > >> new version should be used after such changes are made.
> > > > >
> > > > >
> > > > > That makes sense to me - hold off any changes to the versioning
> > > > > semantics/format until after qpidd/tools are moved to their own
> > > > > source trees.
> > > > >
> > > > >
> > > > >> I did create/rename a
> > > > >> bunch of separate versions in JIRA using '-next' versions in
> > > > >> keeping with desire to move them away from the previous versioing
> > > > >> scheme in future (and reflect the next release/version numbers not
> > > > >> being decided in all cases).
> > > > >>
> > > > >> Robbie
> > > > >>
> > > > >
> > > > > Thanks for the info Robbie.
> > > > >
> > > > >
> > > > >> -------------------------------------------------------------------
> > > > >> -- To unsubscribe, e-mail: [hidden email] For
> > > > >> additional commands, e-mail: [hidden email]
> > > > >>
> > > > >>
> > > > >
> > > > > --
> > > > > -K
> > > > >
> > > > > --------------------------------------------------------------------
> > > > > - To unsubscribe, e-mail: [hidden email] For
> > > > > additional commands, e-mail: [hidden email]
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email] For additional
> > > > commands, e-mail: [hidden email]
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [hidden email] For additional
> > > commands, e-mail: [hidden email]
> >
> >
>

--
-K

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Can the next release of the C++ broker and tools be 1.0.0?

aconway.rh
In reply to this post by Justin Ross-3
On Mon, 2015-11-09 at 13:35 -0500, Justin Ross wrote:
> I'm late to this party.
>
> What would you all say to 1.35.0?  

+1, although perhaps voting +1.99.9999 would better reflect the age and
maturity of this discussion, and its compatibility with previous
versions of the discussion.

> I favor the .35. part in order to (1)
> show the continuity with 0.34, and (2) suggest--correctly--that this
> is a
> mature component.  I would consider this an optimization on top of
> the
> above proposed move to 1.0.0, which I like.
>
> Related notes:
>
>  - Since for the foreseeable future the qpid::messaging API will
> remain in
> the qpid-cpp tree, I have come to think that qpid-cpp is in effect a
> library (among other things of course), and so deserves the major
> ("stable
> interface") number.
>
>  - As implied already, in order to be consistent with the other Qpid
> components, I think we should go to simple increment-by-one versions.
>
> Justin
>
> On Mon, Nov 9, 2015 at 1:16 PM, Steve Huston <[hidden email]>
> wrote:
>
> > +1
> >
> > > -----Original Message-----
> > > From: Chuck Rolke [mailto:[hidden email]]
> > > Sent: Monday, November 09, 2015 1:15 PM
> > > To: [hidden email]
> > > Subject: Re: Can the next release of the C++ broker and tools be
> > > 1.0.0?
> > >
> > > It has been moved and seconded that the C++ broker and tools be
> > > 1.0.0.
> > All
> > > in favor say 'aye'.
> > >
> > > +1
> > >
> > > ----- Original Message -----
> > > > From: "Robbie Gemmell" <[hidden email]>
> > > > To: [hidden email]
> > > > Sent: Monday, November 9, 2015 9:41:55 AM
> > > > Subject: Re: Can the next release of the C++ broker and tools
> > > > be 1.0.0?
> > > >
> > > > On 9 November 2015 at 14:11, Ken Giusti <[hidden email]>
> > > > wrote:
> > > > > See inline:
> > > > >
> > > > > ----- Original Message -----
> > > > > > From: "Robbie Gemmell" <[hidden email]>
> > > > > > To: [hidden email]
> > > > > > Sent: Thursday, November 5, 2015 9:22:07 AM
> > > > > > Subject: Re: Can the next release of the C++ broker and
> > > > > > tools be
> > 1.0.0?
> > > > > >
> > > > > > On 5 November 2015 at 13:52, Ken Giusti <[hidden email]
> > > > > > > wrote:
> > > > > > > Folks,
> > > > > > >
> > > > > > > Given that we're able to release qpid-tools and qpidd
> > > > > > > broker
> > > > > > > independently for the API libraries, isn't it about time
> > > > > > > we
> > > > > > > bestow the honor of a
> > > > > > > 1.0.0
> > > > > > > version to these packages?
> > > > > > >
> > > > > > > These packages do not offer a "public API" as the
> > > > > > > libraries do,
> > > > > > > so technically semantic versioning rules don't apply. But
> > > > > > > those
> > > > > > > rules do define a major release of 0 (eg. 0.Y.Z) as being
> > > > > > > an
> > > > > > > "initial development release".  Furthermore, that's the
> > > > > > > common
> > > > > > > public perception of any software released with a 0.x.y
> > > > > > > version,
> > IMHO.
> > > > > > >
> > > > > > > For qpidd/tools - we're way, way beyond that.
> > > > > > >  qpidd/tools are
> > > > > > > mature to the point where existing functionality is
> > > > > > > stable.  If
> > > > > > > we were to deprecate features, we'd want to increment the
> > > > > > > X
> > > > > > > factor anyways, so at some point we really have to move
> > > > > > > beyond
> > > > > > > 0.x.y.
> > > > > > >
> > > > > > > qpidd 1.0.0 shouldn't be in the same category as nuclear
> > > > > > > fusion
> > > > > > > or flying cars, right?
> > > > > > >
> > > > > > > --
> > > > > > > -K
> > > > > > >
> > > > > >
> > > > > >
> > > > > > Prior discussion on this (perhaps a year ago?) was that the
> > > > > > qpid-cpp version would indeed be changed, probably to
> > > > > > something
> > > > > > like 33.0 (at the time), i.e move the dot[s] from prior
> > > > > > release
> > > > > > number cadence as a starting point.
> > > > >
> > > > > Ah, yes - I recall that also.  I've gotten that mixed up with
> > > > > the
> > > > > decision to use semantic versioning for proton + qpid
> > > > > -dispatch.
> > > > >
> > > > >
> > > > > Personally, I'm not a fan of the N.x versioning approach,
> > > > > even when
> > > > > it comes to a standalone service like qpidd/tools (e.g. not a
> > > > > library).  As I mentioned above semantic versioning provides
> > > > > a bit
> > > > > more detail about the extent of changes in a given release.
> > > > >
> > > > > So the first question I should've asked is:  Can we move
> > > > > qpidd/tools
> > > > > to semantic versioning?
> > > > >
> > > >
> > > > Sounds like a good idea to me.
> > > >
> > > > >
> > > > > > The idea was also discussed to move the components to their
> > > > > > own
> > > > > > source trees aligned on what would be released together
> > > > > > (independently of other bits), in this case having the cpp
> > > > > > broker
> > > > > > and its tools in the same tree was proposed.
> > > > > >
> > > > > > The proposed relocation work was done for the Java bits
> > > > > > (initial
> > > > > > independent release with new version yet to happen, but is
> > > > > > slated
> > > > > > soon as 6.0.0), and such alignment was implicit from the
> > > > > > start for
> > > > > > things like proton/dispatch/jms. Nothing had changed in
> > > > > > that regard
> > > > > > for the other components since those discussions, so when
> > > > > > the most
> > > > > > recent qpid-cpp release was desired I simply continued with
> > > > > > 0.34
> > > > > > from the previous version scheme. I think it makes sense
> > > > > > the first
> > > > > > new version should be used after such changes are made.
> > > > >
> > > > >
> > > > > That makes sense to me - hold off any changes to the
> > > > > versioning
> > > > > semantics/format until after qpidd/tools are moved to their
> > > > > own
> > > > > source trees.
> > > > >
> > > > >
> > > > > > I did create/rename a
> > > > > > bunch of separate versions in JIRA using '-next' versions
> > > > > > in
> > > > > > keeping with desire to move them away from the previous
> > > > > > versioing
> > > > > > scheme in future (and reflect the next release/version
> > > > > > numbers not
> > > > > > being decided in all cases).
> > > > > >
> > > > > > Robbie
> > > > > >
> > > > >
> > > > > Thanks for the info Robbie.
> > > > >
> > > > >
> > > > > > -----------------------------------------------------------
> > > > > > --------
> > > > > > -- To unsubscribe, e-mail: [hidden email]
> > > > > > For
> > > > > > additional commands, e-mail: [hidden email]
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > -K
> > > > >
> > > > > -------------------------------------------------------------
> > > > > -------
> > > > > - To unsubscribe, e-mail: [hidden email] For
> > > > > additional commands, e-mail: [hidden email]
> > > > >
> > > >
> > > > ---------------------------------------------------------------
> > > > ------
> > > > To unsubscribe, e-mail: [hidden email] For
> > > > additional
> > > > commands, e-mail: [hidden email]
> > > >
> > > >
> > >
> > > -----------------------------------------------------------------
> > > ----
> > > To unsubscribe, e-mail: [hidden email] For
> > > additional
> > > commands, e-mail: [hidden email]
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]