Re: Qpid C++ and Python 15.02 - Alpha approaches
On Mon, 2015-01-19 at 19:03 +, Fraser Adams wrote: > I know this has been discussed previously, but looking at "15.02" in the > cold hard light of day just looks, well, weird to my eyes :-( > > Perhaps it's just 'cause it's new and I'm not used to seeing versions > like that, but I have to be honest, I'm still not sold. I know there's > reasons for the change etc. etc. but I can't quite mentally gel with it > :-( Oh well I guess I'll just have to get used to it. +1. Version numbers should be based on _counting_. It's been around for a long time, everybody knows how to do it, there's no localization problems (is that the year first or the month) there are no release cycle limitations (wait we already did one this month, we can't call it anything till next month) That's one thing I admire about apple. Iphone 1, 2, 3. What comes next? yes you guesst it iphone 4! Which iphone is newer 3 or 6? Compare microsoft: windows 1, 2, 3, NT, XP, 2000, 2007, Vista, ME (wait when was ME?) 7, 8. I think I missed a few, and got them in the wrong order. See the problem? Write me a program that takes 2 MS versions and tells you whether you're upgrading or downgrading. Do the same for iphones. All non-counting approaches to versioning are FADS. Even MS are back to counting now. They just leave you with a trail of unintelligible identifiers and frustrated packagers in your wake. What comes after 0? 1. Major.minor.release. It's not new, its not exciting, but it works. > > Frase > > On 19/01/15 12:22, Justin Ross wrote: > > Hi, everyone. I've begun the process to release the C++ and Python > > components. You can see more details at the release pages: > > > >https://cwiki.apache.org/confluence/display/qpid/Qpid+Cpp+15.02 > >https://cwiki.apache.org/confluence/display/qpid/Qpid+Python+15.02 > > > > Alpha is set for the 28th of this month, and Beta (and release branching) > > will follow two weeks after that. Remember to complete major work by the > > Alpha deadline so we can test the build and distribution metadata. > > > > I've made an initial pass and found some failures: > > > >http://people.apache.org/~jross/qpid-cpp-20150116/ > >Proton ABI change causes build failure: > > http://people.apache.org/~jross/qpid-cpp-20150116/cpp-test.out > > > >http://people.apache.org/~jross/qpid-python-20150116/ > >Tools install failure: > > http://people.apache.org/~jross/qpid-cpp-20150116/tools-test.out > > > > Justin > > > > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Qpid C++ and Python 15.02 - Alpha approaches
FWIW I quite like your suggestion below about the Firefox style. It's enough of a change getting rid of the 0. part to signal maturity, but it essentially follows the existing convention, so is unlikely to be too confusing to anyone (plus it looks less weird :-)) Can someone remind me what the perceived compelling advantage of a date based system was? From what I see in general about products date based approaches appear quite rare the only big one I can think of was Microsoft Windows and Office, but MS have ditched dates in favour of numbers too. So +1 from me for Justin's new suggestion (and sorry for bringing this up again I'm afraid I saw 15.02 and went, eeewww) Frase On 19/01/15 19:30, Justin Ross wrote: We can still change it. I know Robbie isn't sold either, and I'm open to the alternative we discussed: 3.1, 3.2, 3.3, etc. I should note that while I think the date-based approach is reasonable, it's not a good fit for a pure-API module such as qpid-proton or qpid-jms. There I think you want the major number to signal the presence or absence of big API changes. Since it wasn't mentioned before: I also like 31, 32, 33 for Qpid C++ and similar. It's the style that Firefox uses, and I think it does a slightly better job of representing the pace and lifecycle of some of our components. Stated negatively, it avoids the major number becoming arbitrary--more marketing than substance. In summary, my preference: Pure API modules such as qpid-jms, -proton: 0.1, 0.2, 1.0, 1.1, 2.0, 2.1, etc. Servers, tools, test suites: 31, 32, 33, 33.1, etc. Justin On Mon, Jan 19, 2015 at 2:03 PM, Fraser Adams wrote: I know this has been discussed previously, but looking at "15.02" in the cold hard light of day just looks, well, weird to my eyes :-( Perhaps it's just 'cause it's new and I'm not used to seeing versions like that, but I have to be honest, I'm still not sold. I know there's reasons for the change etc. etc. but I can't quite mentally gel with it :-( Oh well I guess I'll just have to get used to it. Frase On 19/01/15 12:22, Justin Ross wrote: Hi, everyone. I've begun the process to release the C++ and Python components. You can see more details at the release pages: https://cwiki.apache.org/confluence/display/qpid/Qpid+Cpp+15.02 https://cwiki.apache.org/confluence/display/qpid/Qpid+Python+15.02 Alpha is set for the 28th of this month, and Beta (and release branching) will follow two weeks after that. Remember to complete major work by the Alpha deadline so we can test the build and distribution metadata. I've made an initial pass and found some failures: http://people.apache.org/~jross/qpid-cpp-20150116/ Proton ABI change causes build failure: http://people.apache.org/~jross/qpid-cpp-20150116/cpp-test.out http://people.apache.org/~jross/qpid-python-20150116/ Tools install failure: http://people.apache.org/~jross/qpid-cpp-20150116/tools-test.out Justin - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Qpid C++ and Python 15.02 - Alpha approaches
On 01/20/2015 04:27 PM, Rafael Schloming wrote: The JIRA workflow I've used for proton to date has somewhat depended on being able to predict the next release number given the current release number. I would argue that's a nice property to have for version numbers in general, e.g. being able to say things like "next version" and "prior version" and have that map to something obvious relative to the current version is I think a generally user friendly thing to do. Agreed. Having some understanding of expected timeline (and ideally scope) for the next release (and ideally even the subsequent one, since the question is often 'if not now, when?') is also user friendly. If we get better at sharing release schedules, I think the value in the dated release numbering is less important, since there is more likely to be a well documented history as well. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Qpid C++ and Python 15.02 - Alpha approaches
On 01/20/2015 03:57 PM, Steve Huston wrote: -Original Message- From: Gordon Sim [mailto:g...@redhat.com] Sent: Tuesday, January 20, 2015 10:49 AM To: users@qpid.apache.org Subject: Re: Qpid C++ and Python 15.02 - Alpha approaches On 01/20/2015 03:37 PM, Justin Ross wrote: http://qpid.2158936.n2.nabble.com/Any-ETA-on-a-QPid-0-32-release- td761 7054.html Yes, the generally agreed goal is to move away from "0." for our now mature components. I don't think any suggestion was made about Proton. Most participants on that thread favored a YY.MM (Year, Month) scheme, so that's where I started. The main advantage I see from the year/month scheme is the ability to relate different component versions to each other. E.g. 15.06 of component X was released at the same time 15.06 of component y was, but after 15.01 of component z and before 15.12 of component, um, a, lets say. Ok, but a month is a long time and if components aren't released "together" then both in the same month may not mean much. Yes, but I would hope they would be at least compatible and somewhat tested against each other, if they are planned for the same month. Of course the time taken to actually get ready for release may vary, and one will go out before the other, but the changes to the later components release should not be so extensive as to break things. Our current testing across/between components is not very good. I would hope however that going forward, everything released would be tested against the last release of other relevant components. I.e. you really only get benefit out if this if it is used fairly broadly across components that are released at different times. While I see some advantage from this scheme, there are different advantages for other schemes so I have no desire to impose this it. However if there isn't sufficient agreement to use it more widely than just the qpid-cpp and related bits, I'm not sure it has much advantage (and it is definitely a bit unusual). It is unusual. Not necessarily bad, but it will require more explanation and attention because of the confusion it would cause. Also, what do we mark JIRA entries with for "fix version"? If we don't know the time a next release will come, it's hard to mark the next release, and our current odd-even won't work any longer either. It's important to be able to tell when a bug was fixed. One thing I do think is essential is a clear, public release schedule for each component. (That can of course be updated as necessary, with the community as whole consulted and kept in the loop). This along with the commitment to do a reasonable level of interop testing for every released component is the only thing I feel strongly about. The versioning scheme is not as important if we do those. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Qpid C++ and Python 15.02 - Alpha approaches
On Tue, Jan 20, 2015 at 10:57 AM, Steve Huston wrote: > Sorry to chime in late on this - I saw the discussions going by in > December but paid no attention as I was mostly not working then. > > > -Original Message- > > From: Gordon Sim [mailto:g...@redhat.com] > > Sent: Tuesday, January 20, 2015 10:49 AM > > To: users@qpid.apache.org > > Subject: Re: Qpid C++ and Python 15.02 - Alpha approaches > > > > On 01/20/2015 03:37 PM, Justin Ross wrote: > > > http://qpid.2158936.n2.nabble.com/Any-ETA-on-a-QPid-0-32-release- > > td761 > > > 7054.html > > > > > > Yes, the generally agreed goal is to move away from "0." for our now > > > mature components. I don't think any suggestion was made about Proton. > > > > > > Most participants on that thread favored a YY.MM (Year, Month) scheme, > > > so that's where I started. > > > > The main advantage I see from the year/month scheme is the ability to > relate > > different component versions to each other. E.g. 15.06 of component X was > > released at the same time 15.06 of component y was, but after 15.01 of > > component z and before 15.12 of component, um, a, lets say. > > Ok, but a month is a long time and if components aren't released > "together" then both in the same month may not mean much. > > > I.e. you really only get benefit out if this if it is used fairly > broadly across > > components that are released at different times. > > > > While I see some advantage from this scheme, there are different > > advantages for other schemes so I have no desire to impose this it. > > However if there isn't sufficient agreement to use it more widely than > just > > the qpid-cpp and related bits, I'm not sure it has much advantage (and > it is > > definitely a bit unusual). > > It is unusual. Not necessarily bad, but it will require more explanation > and attention because of the confusion it would cause. > > Also, what do we mark JIRA entries with for "fix version"? If we don't > know the time a next release will come, it's hard to mark the next release, > and our current odd-even won't work any longer either. It's important to be > able to tell when a bug was fixed. > This is a good point. The JIRA workflow I've used for proton to date has somewhat depended on being able to predict the next release number given the current release number. I would argue that's a nice property to have for version numbers in general, e.g. being able to say things like "next version" and "prior version" and have that map to something obvious relative to the current version is I think a generally user friendly thing to do. --Rafael
Re: Qpid C++ and Python 15.02 - Alpha approaches
On Tue, Jan 20, 2015 at 10:37:25AM -0500, Justin Ross wrote: > http://qpid.2158936.n2.nabble.com/Any-ETA-on-a-QPid-0-32-release-td7617054.html > > Yes, the generally agreed goal is to move away from "0." for our now mature > components. I don't think any suggestion was made about Proton. > > Most participants on that thread favored a YY.MM (Year, Month) scheme, so > that's where I started. The only thing in this that kind of troubles me is using the month in the version. I don't mind the year component, but have the 14.x be replaced by 15.3 (assuming a march release) seems very strange. I would find it more sensible for the subcomponent to be 0-based, so that we have YY.0, YY.1, YY.2, etc. Also, should we plan ahead for the Y2100 problem with this versioning scheme? :D -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgp_k_cUA1nfr.pgp Description: PGP signature
RE: Qpid C++ and Python 15.02 - Alpha approaches
Sorry to chime in late on this - I saw the discussions going by in December but paid no attention as I was mostly not working then. > -Original Message- > From: Gordon Sim [mailto:g...@redhat.com] > Sent: Tuesday, January 20, 2015 10:49 AM > To: users@qpid.apache.org > Subject: Re: Qpid C++ and Python 15.02 - Alpha approaches > > On 01/20/2015 03:37 PM, Justin Ross wrote: > > http://qpid.2158936.n2.nabble.com/Any-ETA-on-a-QPid-0-32-release- > td761 > > 7054.html > > > > Yes, the generally agreed goal is to move away from "0." for our now > > mature components. I don't think any suggestion was made about Proton. > > > > Most participants on that thread favored a YY.MM (Year, Month) scheme, > > so that's where I started. > > The main advantage I see from the year/month scheme is the ability to relate > different component versions to each other. E.g. 15.06 of component X was > released at the same time 15.06 of component y was, but after 15.01 of > component z and before 15.12 of component, um, a, lets say. Ok, but a month is a long time and if components aren't released "together" then both in the same month may not mean much. > I.e. you really only get benefit out if this if it is used fairly broadly > across > components that are released at different times. > > While I see some advantage from this scheme, there are different > advantages for other schemes so I have no desire to impose this it. > However if there isn't sufficient agreement to use it more widely than just > the qpid-cpp and related bits, I'm not sure it has much advantage (and it is > definitely a bit unusual). It is unusual. Not necessarily bad, but it will require more explanation and attention because of the confusion it would cause. Also, what do we mark JIRA entries with for "fix version"? If we don't know the time a next release will come, it's hard to mark the next release, and our current odd-even won't work any longer either. It's important to be able to tell when a bug was fixed. -Steve
Re: Qpid C++ and Python 15.02 - Alpha approaches
On 01/20/2015 03:37 PM, Justin Ross wrote: http://qpid.2158936.n2.nabble.com/Any-ETA-on-a-QPid-0-32-release-td7617054.html Yes, the generally agreed goal is to move away from "0." for our now mature components. I don't think any suggestion was made about Proton. Most participants on that thread favored a YY.MM (Year, Month) scheme, so that's where I started. The main advantage I see from the year/month scheme is the ability to relate different component versions to each other. E.g. 15.06 of component X was released at the same time 15.06 of component y was, but after 15.01 of component z and before 15.12 of component, um, a, lets say. I.e. you really only get benefit out if this if it is used fairly broadly across components that are released at different times. While I see some advantage from this scheme, there are different advantages for other schemes so I have no desire to impose this it. However if there isn't sufficient agreement to use it more widely than just the qpid-cpp and related bits, I'm not sure it has much advantage (and it is definitely a bit unusual). - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Qpid C++ and Python 15.02 - Alpha approaches
http://qpid.2158936.n2.nabble.com/Any-ETA-on-a-QPid-0-32-release-td7617054.html Yes, the generally agreed goal is to move away from "0." for our now mature components. I don't think any suggestion was made about Proton. Most participants on that thread favored a YY.MM (Year, Month) scheme, so that's where I started. On Tue, Jan 20, 2015 at 10:22 AM, Rafael Schloming wrote: > On Mon, Jan 19, 2015 at 2:30 PM, Justin Ross > wrote: > > > We can still change it. I know Robbie isn't sold either, and I'm open to > > the alternative we discussed: 3.1, 3.2, 3.3, etc. > > > > It might be worth a recap of the original discussion since it happened so > near the holidays, people night not have been around to follow it closely. > I know I pretty much missed the whole thing. > > > > I should note that while I think the date-based approach is reasonable, > > it's not a good fit for a pure-API module such as qpid-proton or > qpid-jms. > > There I think you want the major number to signal the presence or absence > > of big API changes. > > > > +1 > > Did the original discussion have some proposed implication for proton > versioning? > > > > Since it wasn't mentioned before: I also like 31, 32, 33 for Qpid C++ and > > similar. It's the style that Firefox uses, and I think it does a > slightly > > better job of representing the pace and lifecycle of some of our > > components. Stated negatively, it avoids the major number becoming > > arbitrary--more marketing than substance. > > > > In summary, my preference: > > > > Pure API modules such as qpid-jms, -proton: 0.1, 0.2, 1.0, 1.1, 2.0, > 2.1, > > etc. > > Servers, tools, test suites: 31, 32, 33, 33.1, etc. > > > > Is the big impetus here just to have something more "mature" looking, i.e. > have something in front of the dot? > > --Rafael >
Re: Qpid C++ and Python 15.02 - Alpha approaches
On Mon, Jan 19, 2015 at 2:30 PM, Justin Ross wrote: > We can still change it. I know Robbie isn't sold either, and I'm open to > the alternative we discussed: 3.1, 3.2, 3.3, etc. > It might be worth a recap of the original discussion since it happened so near the holidays, people night not have been around to follow it closely. I know I pretty much missed the whole thing. > I should note that while I think the date-based approach is reasonable, > it's not a good fit for a pure-API module such as qpid-proton or qpid-jms. > There I think you want the major number to signal the presence or absence > of big API changes. > +1 Did the original discussion have some proposed implication for proton versioning? > Since it wasn't mentioned before: I also like 31, 32, 33 for Qpid C++ and > similar. It's the style that Firefox uses, and I think it does a slightly > better job of representing the pace and lifecycle of some of our > components. Stated negatively, it avoids the major number becoming > arbitrary--more marketing than substance. > > In summary, my preference: > > Pure API modules such as qpid-jms, -proton: 0.1, 0.2, 1.0, 1.1, 2.0, 2.1, > etc. > Servers, tools, test suites: 31, 32, 33, 33.1, etc. > Is the big impetus here just to have something more "mature" looking, i.e. have something in front of the dot? --Rafael
Re: Qpid C++ and Python 15.02 - Alpha approaches
We can still change it. I know Robbie isn't sold either, and I'm open to the alternative we discussed: 3.1, 3.2, 3.3, etc. I should note that while I think the date-based approach is reasonable, it's not a good fit for a pure-API module such as qpid-proton or qpid-jms. There I think you want the major number to signal the presence or absence of big API changes. Since it wasn't mentioned before: I also like 31, 32, 33 for Qpid C++ and similar. It's the style that Firefox uses, and I think it does a slightly better job of representing the pace and lifecycle of some of our components. Stated negatively, it avoids the major number becoming arbitrary--more marketing than substance. In summary, my preference: Pure API modules such as qpid-jms, -proton: 0.1, 0.2, 1.0, 1.1, 2.0, 2.1, etc. Servers, tools, test suites: 31, 32, 33, 33.1, etc. Justin On Mon, Jan 19, 2015 at 2:03 PM, Fraser Adams wrote: > I know this has been discussed previously, but looking at "15.02" in the > cold hard light of day just looks, well, weird to my eyes :-( > > Perhaps it's just 'cause it's new and I'm not used to seeing versions like > that, but I have to be honest, I'm still not sold. I know there's reasons > for the change etc. etc. but I can't quite mentally gel with it :-( Oh well > I guess I'll just have to get used to it. > > Frase > > > On 19/01/15 12:22, Justin Ross wrote: > >> Hi, everyone. I've begun the process to release the C++ and Python >> components. You can see more details at the release pages: >> >>https://cwiki.apache.org/confluence/display/qpid/Qpid+Cpp+15.02 >>https://cwiki.apache.org/confluence/display/qpid/Qpid+Python+15.02 >> >> Alpha is set for the 28th of this month, and Beta (and release branching) >> will follow two weeks after that. Remember to complete major work by the >> Alpha deadline so we can test the build and distribution metadata. >> >> I've made an initial pass and found some failures: >> >>http://people.apache.org/~jross/qpid-cpp-20150116/ >>Proton ABI change causes build failure: >> http://people.apache.org/~jross/qpid-cpp-20150116/cpp-test.out >> >>http://people.apache.org/~jross/qpid-python-20150116/ >>Tools install failure: >> http://people.apache.org/~jross/qpid-cpp-20150116/tools-test.out >> >> Justin >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > >
Re: Qpid C++ and Python 15.02 - Alpha approaches
I know this has been discussed previously, but looking at "15.02" in the cold hard light of day just looks, well, weird to my eyes :-( Perhaps it's just 'cause it's new and I'm not used to seeing versions like that, but I have to be honest, I'm still not sold. I know there's reasons for the change etc. etc. but I can't quite mentally gel with it :-( Oh well I guess I'll just have to get used to it. Frase On 19/01/15 12:22, Justin Ross wrote: Hi, everyone. I've begun the process to release the C++ and Python components. You can see more details at the release pages: https://cwiki.apache.org/confluence/display/qpid/Qpid+Cpp+15.02 https://cwiki.apache.org/confluence/display/qpid/Qpid+Python+15.02 Alpha is set for the 28th of this month, and Beta (and release branching) will follow two weeks after that. Remember to complete major work by the Alpha deadline so we can test the build and distribution metadata. I've made an initial pass and found some failures: http://people.apache.org/~jross/qpid-cpp-20150116/ Proton ABI change causes build failure: http://people.apache.org/~jross/qpid-cpp-20150116/cpp-test.out http://people.apache.org/~jross/qpid-python-20150116/ Tools install failure: http://people.apache.org/~jross/qpid-cpp-20150116/tools-test.out Justin - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Qpid C++ and Python 15.02 - Alpha approaches
On Mon, Jan 19, 2015 at 7:22 AM, Justin Ross wrote: > Hi, everyone. I've begun the process to release the C++ and Python > components. You can see more details at the release pages: > > https://cwiki.apache.org/confluence/display/qpid/Qpid+Cpp+15.02 > https://cwiki.apache.org/confluence/display/qpid/Qpid+Python+15.02 > > Alpha is set for the 28th of this month, and Beta (and release branching) > will follow two weeks after that. Remember to complete major work by the > Alpha deadline so we can test the build and distribution metadata. > > I've made an initial pass and found some failures: > > http://people.apache.org/~jross/qpid-cpp-20150116/ > Proton ABI change causes build failure: > http://people.apache.org/~jross/qpid-cpp-20150116/cpp-test.out > I believe this is actually ABI compatible, although there is an API change due to the elimination of the redundant struct. (There is a prior thread between Gordon and myself with more details.) --Rafael
Re: Qpid C++ and Python 15.02 - Alpha approaches
On 01/19/2015 12:22 PM, Justin Ross wrote: Hi, everyone. I've begun the process to release the C++ and Python components. You can see more details at the release pages: https://cwiki.apache.org/confluence/display/qpid/Qpid+Cpp+15.02 https://cwiki.apache.org/confluence/display/qpid/Qpid+Python+15.02 Alpha is set for the 28th of this month, and Beta (and release branching) will follow two weeks after that. Remember to complete major work by the Alpha deadline so we can test the build and distribution metadata. I've made an initial pass and found some failures: http://people.apache.org/~jross/qpid-cpp-20150116/ Proton ABI change causes build failure: http://people.apache.org/~jross/qpid-cpp-20150116/cpp-test.out I have a fix for this, will commit shortly. http://people.apache.org/~jross/qpid-python-20150116/ Tools install failure: http://people.apache.org/~jross/qpid-cpp-20150116/tools-test.out Kim, that looks like your new journal related tooling. - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
