Moose releases
Locked
 
|
Hi all,
I have the impression that moose releases are not very much used. I agree that our development process works great (a lot of progress), and that because of this most people working on or with moose use the development version and ignore the release version. At the moment how ever, I still use a pharo 2.0 based image and cannot take the latest development version (as this is pharo 3.0 based and moose 4.9 is frozen). So I tried to revert to using the releases. And there I ran into problems. Both release 4.8 and 4.9 don't work for me. - release 4.8 has a outdated grease version that causes the image to become unstable when you load something that uses grease. This is almost anything, so you can only use the image "as is" - the moose panel of release 4.9 needs to be closed and reopened. Loading PetitDelphi in this image causes several packages to be imported that only work in pharo 3.0. Note also that this is a barrier for new users. I tried to start the discussion on the moose list before how to improve this, but I got very little response. Note that these problems are easy to fix, but these fixes should be back ported to the release. At the moment I have no idea how I should do this, as the release is made with a snapshot, and that is hard to change. Snapshots work great to freeze, but are hard to maintain. PetitDelphi has a configuration that refers to PetitParser (development). PetitParser has a (loaded) configuration that refers to Glamour (development). Glamour has a (loaded) configuration. As the development version (also for pharo 2.0) refers to the latest version of the packages that only work in pharo 3.0. In PetitDelphi I do not want to change the version of PetitParser to the snapshot version, as here the groups not defined, and PetitDelphi only needs a part of PetitParser. So snapshotting the release, forces me to snapshot my configuration of PetitDelphi, and no longer use the configuration of PetitParser. I do not think that this is a good thing, that all projects depending on moose, should create a snapshot when moose is released. Note that this snapshot has to be made before other changes are made! Also continuing the development process on PetitDelphi would no longer work, as it uses a snapshot. I have the feeling that a snapshot really should not be related to a release and should be considered (and modeled as) a separate concept. Because the responsibility for snapshotting is that of the using project, not the owning project. In metaceller I made the possible to record the current loaded versions of a configuration, where it used the configuration. Meaning: of packages and used configurations in the configuration, the version is recorded (symbolic versions are replaced). I showed it to Doru and I could not convince him to use this. I am willing to put time and effort into the moose releases to improve them, but then I want to know what you think about this. Diego _______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
|
|
Hi Diego, Let's clarify a bit the situation :) Until now, we only delivered Moose releases as images. The first goal of Snapshotcello was to enable us to do what we could not do at all over the last 5 years: provide a script that reproduces a released image.
Due to Snapshotcello, our released images can be reproduced. Furthermore, the snapshot also enables us to provide the release in the Pharo configuration browser. I think this is a significant step. From this point of view, Snapshotting is certainly a step the owner wants to do when he releases, and not a user step.
And now, we can start to iterate and improve. I certainly want to do that, but it was more important to focus and get a release out of the door than to wait until we get the perfect solution. As we discussed before, the next step is to generate a configuration version that preserves groups. Your suggested solution is a good start, but there are still unsolved issues. For example, what do we do with configurations for which we do not have publish access, and they do not already have a suitable release?
Back porting is a separate issue. Until now, I wanted to have all efforts focused on keeping the last version safe and have everyone build on top of it. The release is more for people that want to use Moose for analysis, not for programming. And I think we manage to make this a reality: Moose's latest version is essentially continuously usable for programming purposes.
You said that you do not want to move to Moose 5.0. Why not? You will be surprised at how stable it actually is. And now you even get the GTInspector and GTDebugger in the image :). Basically, the interruption in the continuous delivery process of Moose lasted a couple of days. I am using it already in production. I think this is a valuable asset that should be supported by the community.
Back to back porting: even if we would have a configuration version with proper groups, at the moment we could not really back port given that we use the same repository for all versions. To support back porting, we would need to move to a new repository on every new version. This is certainly doable, and perhaps now we got large enough to consider it. But we need automation.
Cheers, Doru On Fri, Nov 15, 2013 at 12:11 PM, Diego Lont <[hidden email]> wrote: Hi all, "Every thing has its own flow"
_______________________________________________ Moose-dev mailing list [hidden email] https://www.iam.unibe.ch/mailman/listinfo/moose-dev |
«
Return to Moose
|
1 view|%1 views
| Free forum by Nabble | Edit this page |