How about we move to 0.5 for the current release and let 0.1.6 become 0.6? The reason I want to do this is because 0.5.0 and if there are any bugs the follow on releases should 0.5.x, and the API will be backwards compatible. However a version change from 0.5 to 0.6 will allow for changes to the API. How do people feel about this?
Are there any issues with moving 0.1.5 to 0.5.0? Aaron On Fri, Jun 7, 2013 at 1:05 PM, Garrett Barton <[email protected]>wrote: > Can get interesting and do what hadoop did and have some funky branch > hoping going on. 0.1.5 can go to 1.0, 0.2.0 can go to 2.0. I think the > branches would be odd if 0.2.0 current was replaced with the 0.1.5 code > base. > > Or leave it as is and deal with the rename starting with 0.2. Might be > simpler that way. Release notes for 0.1.5 would just be large. > > > On Fri, Jun 7, 2013 at 1:01 PM, Tim Williams <[email protected]> wrote: > > > On Fri, Jun 7, 2013 at 12:54 PM, Aaron McCurry <[email protected]> > wrote: > > > I would like to change our current version (or versioning schema) to > > > something a little more appropriate. The current version is 0.1.5, the > > > previous version was 0.1.4 but there were major internal changes > between > > > those 2 versions. The versions should probably be 1.4.0 and 1.5.0 > which > > > will give the ability to have the minor number for bug fixes, e.g. > > "1.5.1". > > > > > > Thoughts on this, I just don't want to release as 0.1.5 and then change > > it > > > soon after to something like 1.x something. > > > > I don't have strong feelings either way other than $version >= 1.0 > > feels like a bigger deal:) Maybe 0.2.0 to achieve similar intent? > > > > --tim > > >
