On Aug 10, 2009, at 6:52 PM, James Turnbull wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Luke Kanies wrote: >>> Thoughts? Doctrinal arguments? >> >> IMO, 'master' should always be the branch we expect people to submit >> code against, which to me means stable. > > How do we distinguish development branches from stable branches? Of > which we might have multiple - for example 0.24.x, 0.25.x, 0.26.x - > whilst I don't envisage much development on some of these we do need > to > be able to go back and say apply a security-related patch. How do > we go > back in this model? Check-out a tag? Apply the patch and tag again?
Tags are only for actual releases, so that doesn't seem to apply. I haven't thought as much about concurrent development paths beyond dev and stable, but in general, it seems you could easily follow either model -- a branch named after the release (only for existing releases, not releases yet to come), and it could be either the next- style dynamically created branch I am leaning toward, or a built-up over time branch. Either way, though, you want to minimize these as much as possible and only ever apply critical fixes, which would probably then result in a new release ASAP. > >> I think we should move to the often-recreated 'next' branch as we >> discussed, probably with an additional 'dev' branch, so we can try >> code out in one of these branches for a while and remove it if it >> doesn't work (without having to revoke code). > > And you know my thoughts on this - I think it's complex and unwieldy > and > I note we rarely have needed to revert code. There are a handful of > instances where we've needed to do this. It also means two separate > methodologies - one for those of us with Git repos and one for > stand-alone patches and diffs (of which there are many). Well, it requires that the release maintainer always convert those stand-alone patches into commits and/or branches in the repo, which you're already doing. It shouldn't be hard to have our script that creates the next branch be able to handle any of these as a source, as long as they're all in the repo. Then it's just a question of maintaining the list itself, making sure you create the appropriate source commits or whatever, and periodically rebuilding the branches, right? > > I think we need a -dev call to argu^H^H discuss the options. :) I'm fine with that, you going to be able to get out of bed for this one? :) Next week would work well for me on that. Any other takers? -- Ah, but I am more perceptive than most of the universe. Especially the parts of the universe that are vacuum. -- James Alan Gardner --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en -~----------~----~----~----~------~----~------~--~---
