Yann Hodique
13 years ago
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 see http://magit.github.com/magit/magit.html for 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 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.
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 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.
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 see http://magit.github.com/magit/magit.html for 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 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.
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 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.