For the CI, have you considered using travis-ci.org? It's very nice and integrates with github.
On Dec 24, 12:14 pm, Yann Hodique <[email protected]> wrote: > Hi all, > > it's been 9 months since the previous official announcement, and some of > our users are craving for a new release. Since I had a some spare time > recently, I took the liberty to wrap version 1.1.0 as a Christmas > present ! > > This version is available for download on the github > page:https://github.com/magit/magit/downloads > > Also seehttp://magit.github.com/magit/magit.htmlfor an online version > of the updated manual. > > Although there is no huge feature or UI change in this release, it's > quite big already, with more than 126 bugfixes (only counting the > reported ones :)) and tons of cosmetic changes. > > 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. > > - [Ramkumar Ramachandra] for people that don't like the 1.0.0 approach > of having submenus for advanced options access, a magit-simple-keys.el > is provided in the contrib/ directory. This is not part of the > official magit distribution, but some might find it a lifesaver. > > - [Hannu Koivisto] as per popular request, the window management feature > of Magit are now a bit more flexible (although still not perfect). See > variable `magit-status-buffer-switch-function' > > - [Llu s Vilanova] a new extension is available for interacting > with stgit. > > - [Peter J. Weisberg] former Magit "submodes" are now major modes > deriving from `magit-mode'. See for example `magit-status-mode', > `magit-log-mode'... > This is conceptually much cleaner, but might require some adjustments > for existing customization code. > > - [Yann Hodique] shipped extensions are now implemented as minor modes, > which means they can easily be toggled (manually or automatically) for > a given repository. Again, this is conceptually cleanre but will > require some adjustments in user configuration, as `require'-ing them > is no longer sufficient. See user manual of details. > > - ... and of course a lot more, by many contributors. Many thanks to you > all ! > > 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 > softwarehttp://repo.or.cz/w/git.git?a=blob;f=Documentation/howto/maintain-git... > 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. > > 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... > > Speaking of that, I'd really like to put in place a Continuous > Integration solution for Magit. I started looking athttp://continuous.iobut > 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.
