I would suggest to let maintainer choose the meaning of their version
number
some people may want to use the date of the release in the version,
other might want to use alphanumeric version (like 1.4.215beta), and
other might want to use subversion revision number as the minor number
=> all those strategies might be good in the context of the package.
About the core package I suggest to keep 2 as the major version number,
after this is chamilo 2. For the middle number I must say that I like
the claroline strategy : when that number increases, it means the db
structure has changed so much that an upgrade script is needed. minor
number means that if you want to upgrade you can do it by overwriting
your files (the db might have changed but the code can handle both
structure, for instance by altering the structure the first time the
code is executed).
I've seen several project using an understandable timestamp (like
2011april13.14:45) as a last version number and I liked it much. So
first simultanesous release can be tagged :
2.1.0::2011june12.13h30
What do you think of that fore core ?
Systho
Le 13/04/2011 14:15, Hans De Bisschop a écrit :
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
