search

branflake2267 / GWT-Maps-V3-Api

GWT Maps V3 Javascript Bindings
Other
144 stars 113 forks source link

Change Release Numbering Scheme #134

Open twistedpair opened 11 years ago

twistedpair commented 11 years ago

@branflake2267

Can the release numbering be changed to X.Y.Z where:

This way first two values are fixed for a given release. The final number, since it should just do bug fixes and is non-api breaking, allows the various update releases. The next push would thus be 3.9.18.

For more frequent builds, we could add -SNAPSHOT as well, so until v3.9.18, folks could consume v3.9.17-SNAPSHOT.

branflake2267 commented 11 years ago

I was using the maven versioning methodology with a postfix. That looks good to me. If you want to change and pull so the next release can be built on it. Maven release auto increments the last number on each release cycle. http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-syntax.html

branflake2267 commented 11 years ago

I moved the 3.10-alpha-1 on last release

branflake2267 commented 11 years ago

Just a note, automatic tagging takes place and heres how that looks :) https://github.com/branflake2267/GWT-Maps-V3-Api/tags

twistedpair commented 11 years ago

I understand you points. Could you clarify what the point of 3.9.0-build-17 is then? When I see that version, I assume it is an internal build. For example, for libraries like Spring all Maven Central releases, barring beta/alpha are 'RELEASE'. I've also seen 'GA' and no postfix.

My concern is merely that library consumers see the next stable release, which is what I believe you're doing with the last three releases to MC. However, I was hoping we could do something inline with other libraries, so we'd have:

or similar.

branflake2267 commented 11 years ago

I added build-17 b/c I felt like it separated it from the maps api versioning a bit more. Since this was a wrapper, I diverted slightly b/c I wasn't exactly inline with the js version. I didn't want someone to get confused with the version of the js wrapper and the version that we released on. The other thought I had was I see everybody doing it how they want so I just kinda choose and went with it. I don't mind, which way it goes, b/c all I do is document it on the home page, so if you prefer the method above I would be fine with that.

Just a note the 3.9.18.RELEASE wouldn't work that great with the automatic increment. Using that would mean the snapshot would look like this 3.9.18.RELEASE-SNAPSHOT and that seems funky.

twistedpair commented 11 years ago

Thanks for elaborating. That clarifies your reasoning and I concur with it. Once we're inline with the API, say 3.10.0, I fancy incrementing the final value if possible for non alpha/beta releases. That being said, you're certainly correct on the disparate names folks use. Some say RC, others say CR. Tomato, tomahto.

Also, I concur on the funky names. I've not personally used the release plugin, so I'll defer to your experience. I'll have to try it out some time. I recall that some coworkers that used it to release to internal company repo's had some choice words for it.

branflake2267 commented 11 years ago

Sounds good.

Could you request permission to release on this issue. Once you have, I can let them know your good to know. Then I can walk you through the steps when you are ready. :)

I wrote the steps down here. I'm hoping to automate them at some point but I haven't figured out how to add github to the settings.xml. http://c.gwt-examples.com/home/maven/sonatype