On Sat, 24 Dec 2011 12:14:37 +0100, Yann Hodique <[email protected]> wrote: > [...] > A brief list of noticeable changes since 1.0.0: > > - [Pieter Praet] behavior of `magit-rewrite-start' has been slighty > changed, now including the base commit in the rewrite list for easier > manipulations in the "status" buffer. See variable > `magit-rewrite-inclusive' for customizing that behavior. > > [...]
Well, no, I actually made it *more* difficult to start rewrites from `magit-status' by replacing the original behaviour of: "start rewrite at REV~1" with the way `git rebase' behaves: "start rewrite at REV" ... which has since been replaced with a defcustom called `magit-rewrite-inclusive' (default = original Magit behaviour), allowing to always use either the original or the rebase-like behaviour, or be asked whether to include the base commit every time `magit-rewrite-start' is invoked. See the discussion starting @ id:"[email protected]", and more specifically the patch @ id:"[email protected]". > [...] > - ... and of course a lot more, by many contributors. Many thanks to you > all ! > [...] I second that, and many thanks to you as well, Yann! > [...] > > Now, about the future. > > Looking back, many (many !) of the fixes that are released today should > have been part of a much earlier maintenance release. Actually I've > even been willing to do that, but the state of "master" didn't make it > easy to pick the relevant fixes. > > So I'd like to take the opportunity to propose that we adopt a new > branching model that would allow us to release subminor versions > more often. > > Since I hate reinventing the wheel, I propose we mainly stick to the Git > way of maintaining software > http://repo.or.cz/w/git.git?a=blob;f=Documentation/howto/maintain-git.txt > with the exception of the "pu" branch, which I think we don't need at > this point (and anyway branch resets would probably not work very well > with a group of maintainers). To paraphrase that document: > > - 'master' branch is used to prepare for the next feature release. In > other words, at some point, the tip of 'master' branch is tagged with > vX.Y.0. > > - 'maint' branch is used to prepare for the next maintenance release. > After the feature release vX.Y.0 is made, the tip of 'maint' branch is > set to that release, and bugfixes will accumulate on the branch, and > at some point, the tip of the branch is tagged with vX.Y.1, vX.Y.2, > and so on. > > - 'next' branch is used to publish changes (both enhancements and fixes) > that (1) have worthwhile goal, (2) are in a fairly good shape suitable > for everyday use, (3) but have not yet demonstrated to be regression > free. New changes are tested in 'next' before merged to 'master'. > > The benefit is double: first it allows disruptive changes to be staged > outside 'master' until they're proven ready, and then 'maint' would be > a good place for many bugfixes, allowing for shorter release cycle. > > Any comments welcome. > > +1; Every self-respecting project should follow this workflow IMO ! > > On another note, I'm starting having trouble living without a proper > test suite for Magit. As we get bigger and more complex, it doesn't seem > reasonable to continue testing by hand (especially since everyone of us > has its own configuration and subset of use cases he's using all the > time. Thinking of extensions, which are still quite easy to break > inadvertently...) > > I've started some very preliminary work in branch 'unit-tests' > (leveraging the ERT library that's now shipping with Emacs), and expect > to come up with something decent by the time 1.2 is out... > That's fantastic news! > Speaking of that, I'd really like to put in place a Continuous > Integration solution for Magit. I started looking at > http://continuous.io but suggestions are highly welcome. Ideally we > should be able to validate Magit with different combinations of Emacs > and Git, and that definitely requires some automation. > > > > I guess that will be all for now. Thanks for reading this far, Merry > Xmas, Happy New Year, and have fun using (Ma)git ! > > > > Thanks, > > Yann. > Peace -- Pieter
