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 <dale.henrichs@gemtalksystems.com> 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