Hi,
I made a small video on how to use Versionner. Versionner allows you to manage project configurations in a smooth way. I know… is not “Kilon’s quality”… but I hope it will help :) cheers, Esteban
|
On 30/04/15 13:50, Esteban Lorenzano wrote:
> I made a small video on how to use Versionner. > Versionner allows you to manage project configurations in a smooth way. Nice, good to see how versionner is supposed to be used Stephan |
In reply to this post by EstebanLM
Thanks esteban
I would not promote groups because we want to get rid of them. Le 30/4/15 13:50, Esteban Lorenzano a
écrit :
Hi, |
In reply to this post by EstebanLM
Esteban
why you did not define the dependencies between the packages? Stef Le 30/4/15 13:50, Esteban Lorenzano a
écrit :
Hi, |
mostly because I wanted to keep the screencast short an easy.
advanced configurations might need package dependencies, but other times you do not need them. Esteban
|
Then we can remove the groups part :)
BTW we should register (put a link and store the videos) these videos somewhere and not let them on youtube. I want to be able to use them for the Mooc Stef mostly because I wanted to keep the screencast short an easy. |
too late. and yesterday I spend 6h to produce 20m video… so I will not try it again in some time… :P
of course. Esteban
|
In reply to this post by stepharo
On 30/04/15 16:02, stepharo wrote:
> I would not promote groups because we want to get rid of them. No we don't. We need first class support for them in the tools. We cannot map variants decently without lots of duplication otherwise. It is a 5 dimensional problem that is not going to get easy. Stephan |
In reply to this post by EstebanLM
On 30/04/15 16:06, Esteban Lorenzano wrote:
> mostly because I wanted to keep the screencast short an easy. > advanced configurations might need package dependencies, but other times > you do not need them. Well, it either is 1st steps in configurations, and then you can keep them out, or it is about configuration management, and then we want to see the required complexity. That can be in several videos, solving the different problems different users might run into. Stephan |
Excellent work Esteban!
Question for the list: What are groups? What do they model? What problem do they solve? (or why are they useful) |
Le 30/4/15 18:06, Sergio Fedi a écrit : > Excellent work Esteban! > > Question for the list: > > What are groups? > > What do they model? > > What problem do they solve? (or why are they useful) Think about them as other configurations. Because they are not much less than that. Avoid them as much as possible. Stef |
In reply to this post by Sergio Fedi
On 30/04/15 18:06, Sergio Fedi wrote:
> Excellent work Esteban! > > Question for the list: > > What are groups? > > What do they model? > > What problem do they solve? (or why are they useful) When managing configurations, choosing the right granularity is critical to reducing the amount of work needed. Groups allow one configuration to be used to manage multiple combinations of packages. With groups it becomes easier to manage variants. Seaside can be used with any combination of adapters, rest, jQuery, Scriptaculous, Bootstrap etc. The simplest example was shown by Esteban in the screencast: in a production environment one might want to not load the test packages, so one has groups core, test and default (=core+test). Our tools currently do not support groups well enough, as we don't register which groups are loaded in the system. Stephan |
Great, thanks everyone for the explanation.
Having said that, there's still something I don't get. If a group is a possible configuration to load packages, then it seems that the "reasonable" possible configurations would be: 1 - Core 2 - Tests + Core (explicitly stated) 3 - Default (Tests + Core, implicit when not specified) but NOT Tests (without the Core) Because you wouldn't want to load the tests of a package without the Core. So, why would you define the Tests as a possible configuration for a Version? |
Sergio,
When you configure the Test package you add the Core as its dependency. eg: spec package: 'Core-Tests' with: [ spec requires: 'Core ]. Regards! Esteban A. Maringolo 2015-04-30 16:06 GMT-03:00 Sergio Fedi <[hidden email]>: > Great, thanks everyone for the explanation. > > Having said that, there's still something I don't get. > > If a group is a possible configuration to load packages, then it seems that > the "reasonable" possible configurations would be: > > 1 - Core > 2 - Tests + Core (explicitly stated) > 3 - Default (Tests + Core, implicit when not specified) > > but NOT > > Tests (without the Core) > Because you wouldn't want to load the tests of a package without the Core. > > So, why would you define the Tests as a possible configuration for a > Version? > > |
Aha! I saw that in your screencast!
Thanks, now I see how Tests = Tests + Core |
Free forum by Nabble | Edit this page |