Hi Stefaan,
A new simultaneous release sometime around end May/June? Considering all
the new features being developed and refactoring being done that's ....
optimistic ... or is our simultaneous release going to be nothing more
then a packaging of the current stable branches (so without any of the
new essential and urgent features)? I was under the impression those
features were essential for those institutions migrating this summer.
All applications / packages which were in the first release were marked
as 1.0.0. A next release could be a 1.1.0 or a 2.0.0, depending on the
scope of the improvements / changes. It's up to every team or person
responsible for a package to determine that. It might be the easiest to
add a 1.0.0 for all projects right now for everything that was done
prior to release of said packages (or even the Beta and RC flavours if
we want to keep the backlog that detailed) and a 2.0.0 beta and 2.0.0
stable for the upcoming release. Additionally maybe a 3.0.0 for things
which are on the horizon but not a priority for the upcoming release.
It's not up to me to determine it, the aforementioned is just a
suggestion, which - and I'm certain of that - in some cases is not the
best solution.
As for "who is doing what where by which date" ... that should go on the
wiki for now. It might be best for every developer / institution to just
add a page or add their activities to a page which can serve as a
general overview. I would keep the list pretty straightforward: package,
estimated deadline and maybe a short description of what is being done.
Dates depend a lot on whether and when an agreement can be reached on
the primary topics. An IRC meeting is fine by me ...
Best regards,
Hans
On 13/04/2011 13:55, Stefaan Vanbillemont wrote:
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
--
*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
