December 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Catalog Entries

by Torsten Bergmann

Hi Sven, so if I understood you correctly you want a single branch for development - lets assume you directly use master for that. If you just load the branch you get the "latest development" things that are still work in progress. Then from time to time you tag a version for release: 1.0, 2.0, 3.0 in your master branch. If today 3.0 is your latest release they should have a load expression to load 3.0. If tomorrow you tag a new release 4.0 you want to them to use the same load expression to get the "latest released". Right? There is no specific meta-tag for that. But as a tag is nothing more than a string applied to a commit for later reference you could additionally tag the commit of 3.0 with a tag "latest" or "latestRelease" and then later (after 4.0 is released) move this tag to the commit that was used for building a new 4.0. I have not tried but as you could delete and/or move tags in git this should be doable in git without any problem. Just google for "tag moving" and "git". Metacello itself does not care - it then will use Metacello new baseline: 'ZTimestamp'; repository: 'github://svenvc/ztimestamp:latestRelease'; load. to ask git for the tag. But it is your responsibility to move the tag "latestRelease" forward manually anytime you do a new release. As you usually tag locally - remember to push the tags afterwards. Double checking afterwards in GitHub helps here. The command git push -f --tags could be helpful here. Hope this solves what you require. Thanks Torsten > Gesendet: Dienstag, 18. Dezember 2018 um 12:54 Uhr > Von: "Sven Van Caekenberghe" <sven(a)stfx.eu> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] Catalog Entries > > > > > On 18 Dec 2018, at 12:48, Torsten Bergmann <astares(a)gmx.de> wrote: > > > > Hi Sven, > > > > did you try to just use the branch name as in the other model. > > > > Metacello new > > baseline: 'ZTimestamp'; > > repository: 'github://svenvc/ztimestamp:master'; > > load. > > > > then it should load the latest from this branch independent from the > > tags. > > > > Bye > > T. > > I know about master and what it means, but that is not exactly what I want. > > When you release, that is a deliberate action: you put a stamp on the current project timeline, declaring it as ready/stable enough for people to depend on. > > The master branch can further evolve after a (latest) release. It is the next release candidate. > > I would like to depend on whatever released version is the latest. See the URLs in my previous email. > > >

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Ben Coman

On Tue, 18 Dec 2018 at 19:12, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I am trying to load https://github.com/svenvc/ztimestamp/releases/latest > which is actually https://github.com/svenvc/ztimestamp/releases/tag/v24 > > The following works because that is the whole idea of releases (which are > just tags) > > Metacello new > baseline: 'ZTimestamp'; > repository: 'github://svenvc/ztimestamp:v24'; > load. > > But I would like to do > > Metacello new > baseline: 'ZTimestamp'; > repository: 'github://svenvc/ztimestamp:latest'; > This might be something good to have as a community convention, but "latest" on its own is a bit ambiguous. Reading your subsequent post maybe "latestRelease" would be good (or "lastRelease"), to distinguish "latestStable" which is similar but not necessarily a release. (or maybe I'm being too pedantic) cheers -ben load. > > Maybe that is not possible, maybe that has to be done in another way. > > I know about master or other branch names, I was hoping latest was > moving/tracking like https://github.com/svenvc/ztimestamp/releases/latest > does > > > On 18 Dec 2018, at 12:05, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > > > > > > > > On Tue, Dec 18, 2018 at 12:00 PM Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > > > > > > On 17 Dec 2018, at 20:18, Torsten Bergmann <astares(a)gmx.de> wrote: > > > > > > Model 1: Work with a single branch and close a release using a tag as > version in git > > > > =================================================================================== > > > This is I guess how Iceberg, Calypso and others are maintained now. > You work on a specific (development) branch and > > > use the git tagging to mark release like milestone of your project > ("versions"). > > > > > > This is the model I started to maintain ConfigurationOfTealight (which > you will find in catalog > > > and in https://github.com/astares/Tealight) > > > > > > So I tagged in git when I reached something shareable as you can see > on the first releases: https://github.com/astares/Tealight/releases > > > and then reference this git tagged version in my > ConfigurationOfTealight: > > > > > > v0_0_4: spec > > > <version: '0.0.4'> > > > > > > spec for: #'common' do: [ > > > spec blessing: #'stable'. > > > spec > > > baseline: 'Tealight' with: [ > > > spec > > > className: 'BaselineOfTealight'; > > > repository: > 'github://astares/Tealight:0.0.4/repository' ]] > > > > > > > > > The advantage is that you use git to tag the releases, it is a > reproducable stable version then and GitHub shows it on > > > the "releases" tab. One typically can not modify the release > afterwards (which is not 100% true as git tags could be moved but this is > > > another story). > > > > > > So with this model you form and finalize/close a release by tagging in > git/GitHub and reference it in your ConfigurationOf.... > > > > Would it not be possible to refer to the latest release ? For example: > > > > > github://astares/Tealight:latest/repository > > > > That way one would no longer have to update the ConfigurationOf (just > like the BaselineOf does not have to be updated), just making a new release > would be enough. > > > > I tried, but I get Revspec 'latest' not found. > > > > I'm following the conversation in diagonal, but if this error is raised > by metacello's iceberg integration it would mean that Tealight has no > commitish (tag/branch) with the name latest. > > >

Dec. 18, 2018

[Pharo 7.0] Build #57: 22780 Fix uncategorized classes in MonticelloGUI

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #57 was: FAILURE. The Pull Request #2078 was integrated: "22780 Fix uncategorized classes in MonticelloGUI" Pull request url: https://github.com/pharo-project/pharo/pull/2078 Issue Url: https://pharo.fogbugz.com/f/cases/22780 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Sven Van Caekenberghe

> On 18 Dec 2018, at 12:48, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi Sven, > > did you try to just use the branch name as in the other model. > > Metacello new > baseline: 'ZTimestamp'; > repository: 'github://svenvc/ztimestamp:master'; > load. > > then it should load the latest from this branch independent from the > tags. > > Bye > T. I know about master and what it means, but that is not exactly what I want. When you release, that is a deliberate action: you put a stamp on the current project timeline, declaring it as ready/stable enough for people to depend on. The master branch can further evolve after a (latest) release. It is the next release candidate. I would like to depend on whatever released version is the latest. See the URLs in my previous email.

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Torsten Bergmann

Hi Sven, did you try to just use the branch name as in the other model. Metacello new baseline: 'ZTimestamp'; repository: 'github://svenvc/ztimestamp:master'; load. then it should load the latest from this branch independent from the tags. Bye T.

Dec. 18, 2018

[Pharo 7.0] Build #56: 22760 RBRefactoryClassChange should define #isAbstract with true

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #56 was: FAILURE. The Pull Request #2084 was integrated: "22760 RBRefactoryClassChange should define #isAbstract with true" Pull request url: https://github.com/pharo-project/pharo/pull/2084 Issue Url: https://pharo.fogbugz.com/f/cases/22760 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Sven Van Caekenberghe

I am trying to load https://github.com/svenvc/ztimestamp/releases/latest which is actually https://github.com/svenvc/ztimestamp/releases/tag/v24 The following works because that is the whole idea of releases (which are just tags) Metacello new baseline: 'ZTimestamp'; repository: 'github://svenvc/ztimestamp:v24'; load. But I would like to do Metacello new baseline: 'ZTimestamp'; repository: 'github://svenvc/ztimestamp:latest'; load. Maybe that is not possible, maybe that has to be done in another way. I know about master or other branch names, I was hoping latest was moving/tracking like https://github.com/svenvc/ztimestamp/releases/latest does > On 18 Dec 2018, at 12:05, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > > On Tue, Dec 18, 2018 at 12:00 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 17 Dec 2018, at 20:18, Torsten Bergmann <astares(a)gmx.de> wrote: > > > > Model 1: Work with a single branch and close a release using a tag as version in git > > =================================================================================== > > This is I guess how Iceberg, Calypso and others are maintained now. You work on a specific (development) branch and > > use the git tagging to mark release like milestone of your project ("versions"). > > > > This is the model I started to maintain ConfigurationOfTealight (which you will find in catalog > > and in https://github.com/astares/Tealight) > > > > So I tagged in git when I reached something shareable as you can see on the first releases: https://github.com/astares/Tealight/releases > > and then reference this git tagged version in my ConfigurationOfTealight: > > > > v0_0_4: spec > > <version: '0.0.4'> > > > > spec for: #'common' do: [ > > spec blessing: #'stable'. > > spec > > baseline: 'Tealight' with: [ > > spec > > className: 'BaselineOfTealight'; > > repository: 'github://astares/Tealight:0.0.4/repository' ]] > > > > > > The advantage is that you use git to tag the releases, it is a reproducable stable version then and GitHub shows it on > > the "releases" tab. One typically can not modify the release afterwards (which is not 100% true as git tags could be moved but this is > > another story). > > > > So with this model you form and finalize/close a release by tagging in git/GitHub and reference it in your ConfigurationOf.... > > Would it not be possible to refer to the latest release ? For example: > > > github://astares/Tealight:latest/repository > > That way one would no longer have to update the ConfigurationOf (just like the BaselineOf does not have to be updated), just making a new release would be enough. > > I tried, but I get Revspec 'latest' not found. > > I'm following the conversation in diagonal, but if this error is raised by metacello's iceberg integration it would mean that Tealight has no commitish (tag/branch) with the name latest.

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Alexandre Bergel

I believe it is important to remove obsolete entries in the catalog. Having a new empty MetaRepo for each Pharo version seems like a good strategy. Forcing people to republish their configurations when necessary is a good filtering mechanism. Cheers, Alexandre > On Dec 17, 2018, at 1:16 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > So we have the Catalog with version specific repositories for ConfigurationOfXYZ packages/classes. > > I am assuming that we will be keeping this system for at least Pharo 7 and possibly 8. > > Can one define Catalog entries using BaselineOfXYZ ? > Is that recommended ? > Or should a mostly empty ConfigurationOfXYZ be used that internally refers to the BaselineOfXYZ ? > > Sven > >

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Guillermo Polito

On Tue, Dec 18, 2018 at 12:00 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > On 17 Dec 2018, at 20:18, Torsten Bergmann <astares(a)gmx.de> wrote: > > > > Model 1: Work with a single branch and close a release using a tag as > version in git > > > =================================================================================== > > This is I guess how Iceberg, Calypso and others are maintained now. You > work on a specific (development) branch and > > use the git tagging to mark release like milestone of your project > ("versions"). > > > > This is the model I started to maintain ConfigurationOfTealight (which > you will find in catalog > > and in https://github.com/astares/Tealight) > > > > So I tagged in git when I reached something shareable as you can see on > the first releases: https://github.com/astares/Tealight/releases > > and then reference this git tagged version in my ConfigurationOfTealight: > > > > v0_0_4: spec > > <version: '0.0.4'> > > > > spec for: #'common' do: [ > > spec blessing: #'stable'. > > spec > > baseline: 'Tealight' with: [ > > spec > > className: 'BaselineOfTealight'; > > repository: > 'github://astares/Tealight:0.0.4/repository' ]] > > > > > > The advantage is that you use git to tag the releases, it is a > reproducable stable version then and GitHub shows it on > > the "releases" tab. One typically can not modify the release afterwards > (which is not 100% true as git tags could be moved but this is > > another story). > > > > So with this model you form and finalize/close a release by tagging in > git/GitHub and reference it in your ConfigurationOf.... > > Would it not be possible to refer to the latest release ? For example: > > > github://astares/Tealight:latest/repository > > That way one would no longer have to update the ConfigurationOf (just like > the BaselineOf does not have to be updated), just making a new release > would be enough. > > I tried, but I get Revspec 'latest' not found. > I'm following the conversation in diagonal, but if this error is raised by metacello's iceberg integration it would mean that Tealight has no commitish (tag/branch) with the name latest.

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Sven Van Caekenberghe

> On 17 Dec 2018, at 20:18, Torsten Bergmann <astares(a)gmx.de> wrote: > > Model 1: Work with a single branch and close a release using a tag as version in git > =================================================================================== > This is I guess how Iceberg, Calypso and others are maintained now. You work on a specific (development) branch and > use the git tagging to mark release like milestone of your project ("versions"). > > This is the model I started to maintain ConfigurationOfTealight (which you will find in catalog > and in https://github.com/astares/Tealight) > > So I tagged in git when I reached something shareable as you can see on the first releases: https://github.com/astares/Tealight/releases > and then reference this git tagged version in my ConfigurationOfTealight: > > v0_0_4: spec > <version: '0.0.4'> > > spec for: #'common' do: [ > spec blessing: #'stable'. > spec > baseline: 'Tealight' with: [ > spec > className: 'BaselineOfTealight'; > repository: 'github://astares/Tealight:0.0.4/repository' ]] > > > The advantage is that you use git to tag the releases, it is a reproducable stable version then and GitHub shows it on > the "releases" tab. One typically can not modify the release afterwards (which is not 100% true as git tags could be moved but this is > another story). > > So with this model you form and finalize/close a release by tagging in git/GitHub and reference it in your ConfigurationOf.... Would it not be possible to refer to the latest release ? For example: > github://astares/Tealight:latest/repository That way one would no longer have to update the ConfigurationOf (just like the BaselineOf does not have to be updated), just making a new release would be enough. I tried, but I get Revspec 'latest' not found.

Dec. 18, 2018