> Am 30.06.2014 um 20:50 schrieb Stephan Eggermont <[email protected]>: > > Kilon wrote: >> I disagreed with this Stephan >> >> "That being said, I am getting a bit nervous about how versioner is >> released. It should aim to improve the way people can work, and not to >> create a single workflow for all people working on pharo projects. I hope my >> >fears are unfounded." >> >> this what I was replying to. > > Ok. The concrete problem we ran into with the current version of Versioner is > that it > wants to resolve dependencies to exact versions. For configurations depending > on Seaside, Magritte or Grease, this is normally unwanted. They should depend > on > the symbolic release versions. With the high number of changes in Pharo, exact > versions have a short lifetime.
I disagree here. Using symbolic versions in a release just seems to be easier to use while being wrong. I'm talking about a "release" here. A release is only useful if you have exact versions. Everything else is asking for trouble and not reliable. That you can read in the mail archives. Nevertheless if you want a workflow where everything is updated in an uncontrolled way so be it. What you are saying is that metacello is lacking support for specifying if baseline symbolic versions should be resolved or not, right? I do not really see how versionner can influence this. Even if versionner would try to solve this in a custom way the configuration of that would have to be put in the metacello config as well. But where? Or did I miss the point? Norbert > > Dale wrote: >> In a programming language where the development environment allows >> script-based tools (as opposed to GUI-based tools) >> it is much easier to construct custom "tools" to support variations in >> workflow >> ... individual developers routinely copy/share scripts that routinely need >> to be customized for their environment ... > > In order to work together effectively in open source projects it is important > that > contributors know what workflow is used in a project. That is easier when the > number of different workflows is limited. Because projects depend on other > projects > the number of combinations of workflow is very large. Scriptable tools can > easily > support these resulting combinations. Building a GUI tool that is both very > flexible > and very easy to use seems to be less easy. > > Stephan
