I don't understand your remark.
Of course Dev branch / future-stable branch/ stable branch/ features
branch / *** of a same application must be related to each other but
different repos or different branch on the same repo is absolutely not
related to the release planning IMHO
Can you go further on the relation between repositories and release
planning ?
If there is no relation but you wanted to start a discussion about
Branch vs separate repo. I think it might be good to keep 2 repos per
package
=> stable with branch named after version number (this allows to patch
specific version and continue support on past version)
=> dev with branches like future-stable and optionally 1 branch per
major features (in order to not break the work of other guys while
implementing but share the work anyway)
Systho
Le 12/04/2011 15:21, Yannick Warnier a écrit :
Just my additional comment here. If we have a structure to save
versions, and even if one version is a complete overhaul of the previous
one, it is still the same application, so even if it s not "ready", it
should go into the dev repository of the same app (well, I mean the
development branch) until it is considered ready for stable by the
maintainer.
The only reason why you might want to do that in a separate repository
is if you don't actually expect users of the app v1 to migrate to v2 at
some point.
Of course, something that should be done is to provide an upgrade script
that saves the data from the previous structure and injects it into the
new (overhauled) structure. It's exhausting to provide these scripts,
but it is also the only way you can ensure user's fidelity for your app
(who wants to be loosing all their data or to have to script into a
system they don't know just to get a few new features or a faster app?).
Further than that, I don't really know the app itself nor how you know
it is ready for stable (that is generally if you have a user base).Y
annick
El mar, 12-04-2011 a las 10:48 +0200, Systho escribió:
Of course it should but this is implied by "when it's ready".
I wanted to bugfix/stabilized/documentation fase to be
time-constrained. I should probably add that constraint on the graph.
Systho
Le 12/04/2011 10:03, Stefaan Vanbillemont a écrit :
Systho,
I follow your workflow but I have 1 remark, If a package is not
ready/candidate for simultaneous release you go back to an
implementation fase and then to a 'release ready' fase.
Shouldn't it go into the bugfix/stabilized/documentation fase??
We should put some more energy into this discussion, what about the
other developers? Hans, as software coordinator, can you see some
future in this?
We could/should try to set some milestones for the next year and try
this workflow.
Can we discuss this on a next dev meeting?
Kind Regards,
Stefaan
Op 8/04/11 15:00, Philippe Van Eerdenbrugghe schreef:
As asked, here is a workflow presenting the release planning
proposition (I didn't put dates on purpose in order to keep it
focused on transitions)
http://support.chamilo.org/projects/chamilo-20/wiki/Planning
Systho
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
