Esteban,
Yeah, it can take time for the culture to change, but the tools do have
to be in place and the early adopters have to beat those tools into
shape ... we are in this phase at the moment I think... once the tools
are in place, then the projects that are feeling the most pain will have
the opportunity to make the transition with a minimum amount of fuss and
if the pain is reduced (which I expect to happen) others will follow ...
Dale
On 06/13/2015 12:56 AM, Esteban Lorenzano wrote:
… and of course I agree 100% with you :)
the real problem is how do we get there, and I’m thinking not just the
tools, but the “cultural change”.
Esteban
On 12 Jun 2015, at 19:41, Dale Henrichs
<[email protected]
<mailto:[email protected]>> wrote:
On 06/12/2015 01:24 AM, Esteban Lorenzano wrote:
it was just an example of why using #stable in project dependences
is a bad idea :)
you made #releaseN.N to fix precisely my point.
but since this is a convention of Seaside and not a regular
practice… who knows it? (not saying that is wrong, is in fact very
good, but there should exist something like I say “3.*”)
btw… IMO other frequent misunderstanding is the use of metacello as
description for nightly builds.
metacello (and any dependency manager) should be use *just* for
releases.
think other dependecy managers around: maven, npm or whatever… they
are used to describe and publish projects people actually can
download and use.
Any version:
3.0
3.0.1
3.1
…
etc.
is a loadable and usable version.
the concept of stable/release/etc. is just incorrect: all published
versions should be stable and released.
we need to separate the concept of “artifact released” and
“development branch”, and we need to stop using versions as commits.
In my opinion development cycle should be:
we release version 1.0
then we develop in bleeding edge lets say for doing a version 1.1
we want a bug fix for 1.0 while developing 1.1? then we install 1.0,
make a fix, and publish 1.0.1
we continue in #bleedingEdge until we are ready to:
1.1-alpha
1.1-beta
1.1-rc1
1.1
we repeat the cycle for next version
etc.
I’m sorry for being obvious here, I know this is known… problem is
that I’ve seen far too much the use of metacello not for doing
releases but to handle commits.
Esteban, this point is exactly the reason that I am a proponent of
using git.
Branches are first class objects in git and provide exactly the type
of functionality that is needed for doing development where problems
are being solved on multiple fronts.
I've added features to the Metacello Scripting API over the last
couple of years to make it possible to switch between github-based
repos and local git clones which is critical for development and
So I don't think that "Metacello shouldn't be used for nightly
builds", but that "ConfigurationOf shouldn't be used for nightly
builds":)
I've recently posted an article on the Metacello news group[1] where
I talk in more detail about using Metacello and git for development.
Dale
[1]http://forum.world.st/GitHub-Configs-tp4830432p4830673.html
