Hans,
I understand the situation we have right now is not desirable and only
temporary. I know a lot of these essential features are still in
development and should be in the next stable release :-)
Can we make a proposal?
step 1: merge frequently the stable into dev (until the day before step
2), current developments should be finished and testend by then (make
list of current developments on dev repos), no new feature development
may start as of today/week (I want to contact all current developers and
summarize their planning).
step 2: merge dev repos into stable repos (end may/begin June), new
development can start again on development repos
step 3: stabilize (bugfixing) the stable repos (organisations that want
can use this stable repos in production)
step 4: new release (end of the summer?)
That way, all organisations that want to migrate this summer, or start
in production next academic year have a set of stable repos to work on.
And it gives us some more time to prepare the simultaneous release.
What do you think?
Kind Regards,
Stefaan
Op 13/04/11 14:15, Hans De Bisschop schreef:
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
_______________________________________________
Dev mailing list
Dev@lists.chamilo.org
http://lists.chamilo.org/listinfo/dev
