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 <r...@alum.mit.edu> wrote: > On Mon, Jan 19, 2015 at 2:30 PM, Justin Ross <justin.r...@gmail.com> > 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 >
