On Jun 29, 2011, at 11:06 PM, Marius Mårnes Mathiesen wrote: > On Wed, Jun 29, 2011 at 7:04 PM, Mike Luu <[email protected]> wrote: > What's the current convention for knowing when gitorious is stable enough to > upgrade? I've been running an internal deployment based on f6a3129 > (2010-06-01) and it's been working fine, but I'm looking forward to > deploying/using some features that are materializing in master. Does > gitorious.org continually get updated as commits are made into > mainline/master? Is there a continuous integration server I can check to > ensure I won't be taking a faulty commit? > > Mike, > The master branch in the mainline repository is stable, it's what we use to > deploy to gitorious.org. Gitorious ships with a test suite that's run before > anything is pushed to the master branch, you can run it yourself (rake test > in the repository root). > > That being said, we will start versioning Gitorious in the very near future > (http://blog.gitorious.org/2011/01/10/versioning-gitorious/). Even if the > master branch "works", from time to time dependencies are added (or better, > removed) from Gitorious, and just pulling the branch won't tell you that you > need to make other changes to your system. By versioning Gitorious we will > document what kind of changes you need to do on your system to go from > version x to y. > > I suppose we should really start versioning Gitorious as soon as possible We > seem to agree on using semantic versioning (http://semver.org), so the only > thing we really need to determine is which version to start on, maybe we > could get some inspiration from: > - The Linux kernel going 3.0 without adding any new features > - Slackware's 13.37 version > > Any ideas?
Marius, Thanks for the info. The numbering scheme doesn't matter so much to me. What I'm looking for is a high level summary of changes from release to release with any known issues for upgrading. BTW, this my first time really speaking up on the list so I'd like to say how much I appreciate this project and it's contributors. Without it, I'd be stuck using Perforce at work, blech :) Cheers, Mike
smime.p7s
Description: S/MIME cryptographic signature
