On Sat, Feb 07, 2015 at 11:40:49AM -0500, Karl Dahlke wrote: > > It may also be interesting to think about having a head branch for > > development > > and a release branch for releases since this'd allow people to follow > > releases > > via git pull without having to worry about getting the latest unstable > > developments. > > Well perhaps - but I'm trying to avoid git version complexity > and branches and the like. > The few intrepid folks who follow the latest often want the latest, > even that last bug or feature that we just fixed, > and they are sometimes helpful in finding more bugs, so we can fix them > *before* any release or version cuts over. > Recall when a user found a seg fault just last month and I fixed it, > and didn't that happen a month before too? > These are our beta testers, and I think they > really do want the latest, and we want them to have the latest. > It's a win win. > Besides, our "unstable" snapshots aren't really that unstable. > We are reasonably careful in what we push.
So if they want the latest they track head. This is very simple in git. If they want the release branch (with bug fixes) they track release. This enables us to do bug fix releases whilst getting on with major developments. For example, currently we're debating whether to release 3.5.3, but also talking about looking at tidy5 based html parsing and all the changes that implies. If there's a bug in 3.5.3 which we don't find, but users do after the release, we'll need a way to fix that, however we can't hold off the tidy5 (or other parsing lib) changes indefinitely (well we can but not if we want to make progress). This hasn't been an issue before due to the incremental nature of changes, however for less incremental changes this will become an issue fairly quickly I suspect. Cheers, Adam.
signature.asc
Description: Digital signature
_______________________________________________ Edbrowse-dev mailing list [email protected] http://lists.the-brannons.com/mailman/listinfo/edbrowse-dev
