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. 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
Hi Stephan, Le 30 juin 2014 à 20:50, Stephan Eggermont a écrit :
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 don't think it is the problem because the solving to exact versions is an option (You have a check box). The real problem is the support of platform-specific sections.
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.
Yes but some part are reusable. For example, Versionner uses MetacelloToolBox that was not thinked to support the current Versionner workflow. Versionner has some classes (model, commands) aside the GUI that can be reused for other workflows. Christophe.
Am 30.06.2014 um 20:50 schrieb Stephan Eggermont <stephan@stack.nl>:
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
participants (3)
-
Christophe Demarey -
Norbert Hartl -
Stephan Eggermont