Hi,
Forgive me if I missed any relevant posts. I also didn’t want this
debate to get caught up in any particular code contribution such as the
new Cartesian editor code from Konstantin. As always, these are my
honest opinions (with a few that were modified after hearing from
others). The last thing I want to do is dictate policy and procedure,
these are suggested policies.
I think that we need to balance adding new features, getting these into
the users hands, translations and stability. Looking around for other
projects that seem to do this well, get packaged widely and have healthy
communities I came away with these ideas. An odd-even release cycle
seemed like a great approach to me. Coupling that with a KDE style
"always summer in trunk" might lead to the ultimate in flexibility and
simplicity (thanks for the link Carsten).
So in future I would propose that odd releases are never branched, but
we can take a snapshot of trunk package it and release it as a beta.
When we are getting ready to make a release we branch for that release
(i.e. 1.2, 1.4, …), that branch becomes feature and string frozen.
Developers can request merges etc, but in general can feel free to leave
the branches alone and continue developing. When it is ready then a
1.2.0 is tagged and releases, 1.2.1 etc. In parallel trunk/master
becomes 1.3 but other than that development can continue as normal. When
1.2 is released, barring major bugs 1.0.y releases would cease.
I also think that David’s idea of having a separate external plugin repo
would work great. The Windows and Mac packagers could add these to their
releases if they wanted to with the caveat that they would not be as
well translated/as well tested. An improved installer that optionally
installed these experimental plugins would be ideal, and the Linux
distros could simply add a package for the extra plugins. This repo
could mirror the Avogadro release numbers to indicate which version it
was tested most against possibly.
I think always summer in trunk would make policy very simple for the
developer community. Master is always open for development, branches are
always frozen in some way (check before pushing stuff to them). So it
should lead to less confusion. This release was long and drawn out, and
there were certainly mistakes that were made. I had not thought, but the
z-matrix editor should have been removed prior to release (I was hoping
to find time to finish it). Our string freeze was more of a slush… I
think we can do better in future though, and I hope we can do that
without alienating any new contributors.
Finally, Konstantin (if you are still reading) - this discussion was no
reflection on the quality of your contribution. This is our first stable
release, and I think as a community we are still finding our feet. 10/23
was a big day and I want to ensure that Avogadro is a great tool that
can be used by the masses. We just need to get some reasonable policies
in place, realize that there may be times when we have to bend/shatter
these policies.
Please feel free to point out errors in my logic, points I missed or
suggest a better release policy/schedule. As for frequency I would
prefer a 9 month stable cycle, with a 1-3 month bug fix release cycle.
If it turns out that trunk is always stable or these policies really do
not fit we can of course change them in the future.
Marcus
PS
Sorry about the delay in replying, it looks like we got bitten by cold
and flu season, and real life has been pretty hectic on top of all that.