3 Dec
2009
3 Dec
'09
6:51 p.m.
On 3 déc. 2009, at 13:56, Stéphane Ducasse wrote:
Let's be stupid: I can reload X Y Z, it's just not so easy sometimes.
At one point in time, we just know that the branch in which we are
working may be ok (partially, because we dont test everything).
Meanwhile, there are plenty of other changes. I just want to be clear
that with this development process, we can not take any development
version as a precise picture of the status of Moose at the time of
development, because in general it is a branch.
So I proposed something in a later mail about creating 'dev' version.
Then one sould be careful it's a dev, not a stable version, so I want
a different name and different numbering schema like 1.3.x
Problem is I dont think Metacello can handle automatic numbering.
Did not scale with Moose-All. Everytime someone committed Moose-All
before you did, you had to be careful with merging.
--
Simon
*About the Moose process*
I dont think the Pharo process and the Moose process compare.
I think that you are wrong. they both need a map. A specification of
what to load
I do not see why saving XXX and not be able to reload XXX package is
cool to your eyes. It makes no sense!
with the current process:
you publish X Y Z and I put Y1 after
and you cannot reload your X Y Z so you are fucked up.
Now you say
map1 = X Y Z
and I say map2 = X Y1 Z
and we can all reload what you want.
You do not have to oppose map or absence behind a process.
You can publish map without having to run test.
With your approach we have no way to spot a vicious bug that
requires to go back in time.
In pharo sometimes we are forced to do that.
This is a technical problem and it has nothing to do with process.
We should have maps.
You did not convince me :)
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.
I disagree. Totally. 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.
This is a crappy and bad way of doing that. This is a SVN
regression. Let us study the commit fingerprint to know what where
the files
that worked together: but we know it and we have a tools to save it.
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'
it will not work because we do not have good test coverage.
Now we know that a version is composed of a set of specific
compoentns so just save it. 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.
We are talking about the wrong tool to fix the problem.
- 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.
come on
it worked in moose in store, it worked with Moose-all (modulo the
subprojects even if I prefered Moose-all than the current situation).