On Wed, Apr 22, 2015 at 7:55 PM, stepharo <steph...@free.fr> wrote: > andrei > > You talk about releasing. > I talk about changes that should be done on a system while people are not > active. >
If we are all on vacation, or you really really need a bug fixed, or you make a change that touches a lot of packages then I see no problem if you make a slice and notify us so we can back port it. What I would like to avoid is this becoming the default behaviour any time you want to make change that is just related to a project that is maintain by configurations. Right now for rubric you can just commit you package to the rubric repo under the pharo team, create a new version using versioner, copy it to PharoInbox50, make an issue to integrate it and integrate it. A few more steps then working with slices but you do not have to wait for us to integrate :). You might get some merge conflicts when we are actively working on rubric but then we are around to help with the merge. Cheers, Andrei > > Stef > > > Le 22/4/15 15:29, Andrei Chis a écrit : > > In all new tools that we did we tried to have only 2-3 packages and use > tags to organize classes in a packaged (GT-* has 9 packages for 3 > projects). > This allows for very simple configurations with clear dependencies. > Glamour has more packages (17) but those should also be reduced, as we do > not need such a low level of granularity. > > Given that support for working with multiple nested configuration is not > great we can merge all GT-* projects into one configuration. > I would still like to have different configurations for Glamour and Rubric > as they are separate projects. > So we can have just three configurations (each one for a separate project > that can be released independent of the others): > > ConfigurationOfGToolkitCore > ----> ConfigurationOfGlamourCore > ---------> ConfigurationOfRubric > > This would make releasing a new version easier with the current support > from versioner. > Releasing a version for all three configurations at once would still > require some manual updating of versions, but that's a less frequent > use-case. > > Cheers, > Andrei > > > On Wed, Apr 22, 2015 at 12:21 PM, Esteban Lorenzano <esteba...@gmail.com> > wrote: > >> exactly. >> what we need in the long term is a complete better integration process. >> I dream to have a git pharo project with submodules and pull requests. >> >> Slowly the tools are coming, but this will take time to implement. >> In the mean time, we need to do all the steps we can to allow us to >> achieve the modularisation goal. >> Even if they look not easy because we are still building it, or too used >> to previous ways of doing it. >> >> Esteban >> >> > On 22 Apr 2015, at 12:15, Pavel Krivanek <pavel.kriva...@gmail.com> >> wrote: >> > >> > And do not forget that with better Pharo modularization it will start >> > to be a problem on more lower level. When eg. Morphic will be an >> > "exteranal" Pharo package. >> > >> > -- Pavel >> > >> > 2015-04-22 12:03 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com>: >> >> >> >> On 22 Apr 2015, at 10:21, Andrei Chis <chisvasileand...@gmail.com> >> wrote: >> >> >> >> But this only works for releasing simple configurations that do not >> depend >> >> on other configurations. >> >> This would work for rubric, for example, but not for other >> configurations we >> >> have in gtools. >> >> >> >> >> >> then you have two options: >> >> >> >> 1) you rewrite your configurations to not need nested configurations. >> This >> >> is not recommendable in huge projects like Seaside, but things like >> GTools >> >> are easily (I did a quick check and your 3 configurations have in >> total 7 >> >> packages… would not be a problem to have them without nesting projects >> and >> >> just using the packages). In fact, this is how Dale recommends using >> >> configurations (if I understood him right). >> >> 2) we enhance the tools to also allow the commit of nested packages. >> >> >> >> I think both approaches needs to be done: you don’t need unnecessary >> >> complexity in your configurations and we need to add some nesting >> support to >> >> commit new version. >> >> >> >> What is not admisible, IMO, is to do something that is wrong just >> because it >> >> looks easier in the short term (and I say “in short term” because what >> looks >> >> easier now will generate a lot of problems in the future). >> >> >> >> cheers, >> >> Esteban >> > >> >> >> > >
