From: Tom C. <Tho...@na...> - 2014-01-30 02:53:21
|
Upon prompting by one of the hopeful users of pFUnit, I'm shifting my somewhat adhoc approach to branching and versioning of pFUnit to a hopefully more standard and user-friendly approach. Branching policy will attempt to follow the recipe provided here: http://nvie.com/posts/a-successful-git-branching-model The main point is that the master branch will be used exclusively for stable releases. I will create a new development branch for routine development using continuous integration. The newly created integration branch will go away, though I would like to implement a better mechanism to test changes more thoroughly prior to pushing to the development branch. (IT security can make some seemingly simple things such a chore.) Then, with regard to numbering revisions, I will endeavor to follow the Semantic Versioning Specification: http://semver.org/ What I've done until now is actually not too different, but my understanding was at best blurry. Short summary is that revisions are of the form x.y.z. z is incremented for backwards compatible bug fixes. y is incremented for backward compatible enhancements, and x is incremented when backward compatibility cannot be maintained. With that in mind, by recent 2.1.0 branch (which should have been a tag) will be the last release before 3.0 which introduced new interfaces for the parser. I've already pushed those changes to the integration branch and hopefully tomorrow will create a development branch and a 3.0 release branch so that interested users can start playing. After we've gained some experience and believe these to be stable, I will formally release 3.0. Saying this out loud primarily for my own benefit. Also, it may be useful to start thinking about a management structure - change review board and all that. (I abhor "process", so I hope to make whatever of this we need as lightweight as possible.) Questions/concerns/objections? Speak quickly. Cheers, - Tom Thomas Clune, Ph. D. <Tho...@na...> Chief, Software Systems Support Office Code 610.3 NASA GSFC 301-286-4635 MS 610.8 B33-C128 <http://ssso.gsfc.nasa.gov> Greenbelt, MD 20771 |