Proposal for releases and schedules going forward

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.

On Sat, Nov 7, 2009 at 2:24 PM, Marcus D. Hanwell marcus@cryos.org wrote:

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).

I like the “always summer in trunk” idea.

http://akademy2008.kde.org/conference/slides/Future_of_the_KDE_development_model.pdf

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.

Sounds good. I’ll leave 1.0 alone from now on. In most cases it should
be obvious from the commit message if the commit needs to be added to
1.0.

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.

This would be nice for windows. Perhaps we can create a wiki page for this.

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.

Yes, the new cartesian editor is a great feature. I was just a bit too
quick to put it in the 1.0 branch.

Tim

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.


Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what’s new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july


Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel

Hi,

My suggestions about stable branch:

  1. No large changes in core components which can lead to crashes and memory leaks
  2. New release of stable brunch should be published after every crash or memory leak fix
  3. Strings in main window must be absolutely freezed. Strings in extensions should be changed if it’s necessary to improve usability. If strings were changed, e-mail must be sent to translators’ mailing list
  4. Exstensions might be backported into stable branch if they were included into 2-3 unstable releases and no related bugs were reported


Regards,
Konstantin

P.S. IMHO, you are too concerned on strings’ translations. However, there are a lot of strings of Qt, which are incomplete and differ depending on platform. For example, “Discard” from save on exit dialog is translated to Russian in Debian unstable, but isn’t translated to Russian on Windows and many Linux distros. User will not have experience of completely translated application anyway.

Regards,
Konstantin