Hans,
Can we start by defining some version numbers for the different
packages/applications & dates for the next releases? So we can move
issues/feature requests? It should make it all a bit clear for everybody
to see the work left in the different applications.
As I see it right now we should have a new simultanious release sometime
around end May/June? So all institutions that want to migrate this
summer have a new stable release with lots of bugfixes.
-Who is busy developing on the dev? fixing on stable? Who is doing what?
Deadlines?
- Date for feature freeze on dev repos? Branching all current dev repos
into a future-stable line?
- Settings a date to merge current stable into dev/future-stable line?
- What should be the composition of that release? What optional apps
should be included?
- Who will test the future stable release?
- Date to release the package? Who will package it?
Lots of questions right now ..
We have to make some decisions here, maybe we can organize an IRC
meeting about it in the next days?
Stefaan.
Op 12/04/11 14:56, Hans De Bisschop schreef:
Stefaan,
As software coordinator I strongly believe this is the only future
that can work to sustain the project / product. It goes without saying
of course, that this can only work if and when everyone agrees to the
rules of the game AND actually follows them ... and it obviously
applies to BOTH the core AND the optional applications. As cruel as it
may sound: "playtime" is over and we need to come to some kind of
consensus or agreement on this as soon as possible.
Best regards,
Hans
On 12/04/2011 10:03, Stefaan Vanbillemont wrote:
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
--
*Hans De Bisschop*
Hoofddeskundige ICTO | Lead Developer Chamilo 2.0
Software Coordinator Chamilo Association
Erasmushogeschool Brussel
Nijverheidskaai 170 | B-1070 Brussel
T 02 559 02 54 | i 254
hans.de.bissc...@ehb.be <mailto:hans.de.bissc...@ehb.be> |
www.erasmushogeschool.be <http://www.erasmushogeschool.be/>
Kom eens langs: www.erasmushogeschool.be/infodagen
<http://www.erasmushogeschool.be/infodagen>
of lees onze elektronische nieuwsbrief: ehbrief.ehb.be
<http://ehbrief.ehb.be/>
P Before printing, think about the environment
_______________________________________________
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
