On Tue, Sep 6, 2011 at 9:08 AM, Marvin Addison <[email protected]> wrote: > I'd like to take the GitHub migration as an opportunity to drop old, > stale, or irrelevant branches from the repository. Pruning dead > branches will help increase clarity about what versions are actively > maintained. I propose the following branches be preserved and mapped > to new branches: > > 1. trunk -> cas-4.0 > 2. cas-3_4_x_maintenance -> master > 3. cas-3_3_x_maintenance -> cas-3.3-maint > 4. cas-3-2_maintenance -> cas-3.2-maint > > Note that the first two changes are part of > https://issues.jasig.org/browse/CAS-997. All other branches would be > deleted, including the LPPE branch and some older (presumably dead) > maintenance branches. Branches like LPPE and other experimental work > can be justifiably purged due to new workflows facilitated by git; for > example, simply clone the repo into a personal GitHub repo, work away, > then send a pull request upon fitness for merging with master. > > Let's simply vote on this proposal and hopefully any severe reaction > will shake out in the voting. Anyone may vote but only votes by > active devs count.
I'd like us to consider this model: http://nvie.com/posts/a-successful-git-branching-model/ both for the branch management and the "Decentralized but centralized" model for active developers (non-committer status would clone and do a pull request) but with remote feature branches to facilitate collaboration. Adopting this model we would end of with something like: Master branch (source code of HEAD always reflects a production-ready state) * tags/cas-3.4.10 -> master Develop branch (source code of HEAD always reflects a state with the latest delivered development changes for the next release) * cas-3_4_x_maintenance -> develop Feature branches (are used to develop new features for the upcoming or a distant future release) * trunk -> cas4-api (feature branch) * cas-server-3.4.10-lppe -> lppe (feature branch) Release branches (as needed, in preparation of a new production release, thus freeing up develop branch for continued evolution) Hotfix branches (as needed, to prepare for a new production release, albeit unplanned, like a security patch) The other maintenance branches could be created as needed from tags. Although I suspect we'd only see future 3.(3/2/1) releases for security issues and only if there are adopters/developers interested in them. I realize that cas4-api as it currently stands is likely to encompasses much more than would be typical for a feature branch, but still think the model could hold up, and particular items could be back ported via additional feature branches. Thoughts? Best, Bill > > M > > -- > You are currently subscribed to [email protected] as: [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
