On 3 déc. 2009, at 13:02, Simon Denier wrote:
*About the Moose process*
I dont think the Pharo process and the Moose process compare.
The Pharo process is about integrating fixes from packages which are
supposed to do one and only one thing, and do it well and is tested.
The Moose process is about developers making incremental changes to
the code base so that they can work and share it immediately. Which
means it can break other things.
Now I'm pretty sure I dont want a release every time someone commits
a package in Moose, because I'm pretty sure this someone didn't run
all the tests before committing. So making a release for each new
commit makes no sense for me. We dont integrate changes, we just
merge when there are some divergent branches. That's why we are
always working with the dev version and the 'default' is one way to
do it.
If we want historical data about Moose, I guess it's still possible
to retrieve all latest packages at a given date. It will not be very
different from what we used at this date.
Now about the *release* process for Moose: sure I would like that
there will be more releases. Now as Doru said, when we do a release,
we should do it for every sub projects and it's bit difficult with
the current tools.
- One way to do automatically it is to use the test server to at
least create a new version from the latest dev version and blessed
it as 'tested' if 100% tests passed or 'broken'
But I dont want such versions to pollute the manual versions, which
are supposed to be stronger. So something like create automatically
'testedVersionXXX' with tests or broken as possible blessing.
- Then we can do manual release from time to time (every two weeks,
every months?), which requires more work as we have to do it for the
different subprojects first, and blessed it as beta or stable.
What people can do if they work with the development version: they can
always save the current versions of packages if they feel happy with
it, in a 'devXXXSimWorkingOnIssue' method blessed as development. This
will be like a branch and he can always start from here next time
(this way, he is not offended by potential breaks in latest dev). But
he should take care that it also merges well with the main trunk in
the end, because that's from where we will make stable release.
--
Simon