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@stfx.eu> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] Catalog Entries
On 18 Dec 2018, at 12:48, Torsten Bergmann <astares@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.