Catalog Entries

> Gesendet: Montag, 17. Dezember 2018 um 17:16 Uhr
> Von: "Sven Van Caekenberghe" <[hidden email]>
> An: "Pharo Development List" <[hidden email]>
> Betreff: [Pharo-dev] Catalog Entries
>
> 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
>
>
>

> On 17 Dec 2018, at 20:18, Torsten Bergmann <[hidden email]> wrote:
>
> Hi Sven,
>
> Maybe we have better ideas when we move forward with the transition to git for the majority of external
> projects. But for the time being I guess we stick to Catalog as a replacement is still not available.
> It might not be the best solution - but at least it works. The only downside is that it is still dependent
> on SmalltalkHub due to the MetaRepos hosted there.
>
> To answer your questions:
>
> For Pharo 7.0 there is a regular MetaRepo
>
>   http://www.smalltalkhub.com/#!/~Pharo/MetaRepoForPharo70
>
> that one can use. The (re)indexing each day is still based on providing a ConfigurationOf... there.
> We will create a MetaRepoForPharo80 once Pharo 7 is released and Pharo 8 work starts.
>
> Catalog also does not work directly with BaselineOf - so you point from your ConfigurationOf to a BaselineOf in Github
> as the examples below will demonstrate.
>
> So while the basic mechanism of Catalog did not change and works as before the usage of git and GitHub gives you now more
> flexibility in the management of your (catalog) projects.
>
> I already use this for a few of my projects that I moved to GitHub and I would share some experience here.
> Basically I tried now two different models:
>
> 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....
>
> Model 2: Work with several open branches - one per Pharo version
> ================================================================
>
> In DesktopManager which is on https://github.com/astares/Pharo-DesktopManager I do it differently. I wanted to maintain it for Pharo7
> now but wanted to still easily backport changes to Pharo 6.
>
> For this project I maintain therefore two special branches "pharo6" and "pharo7" - each for a particular Pharo version.
>
> So in the ConfigurationOfDesktop as you will find in MetaRepoForPharo70 I just point to the Baseline
> with only the difference of the branch:
>
> ------------------------------------------------------------------------------------------------------------
> pharo6: spec
> <version: '6.0'>
>
> spec for: #'common' do: [
> spec
> baseline: 'DesktopManager' with: [
> spec
> className: 'BaselineOfDesktopManager';
> repository: 'github://astares/Pharo-DesktopManager:pharo6/src' ]]
> ------------------------------------------------------------------------------------------------------------
> pharo7: spec
> <version: '7.0'>
>
> spec for: #'common' do: [
> spec
> baseline: 'DesktopManager' with: [
> spec
> className: 'BaselineOfDesktopManager';
> repository: 'github://astares/Pharo-DesktopManager:pharo7/src' ]]
> ------------------------------------------------------------------------------------------------------------
> stable: spec
> <symbolicVersion: #'stable'>
>
> spec for: #'pharo5.x' version: '0.2.0'.   "old way using versioning with Monticello/Metacello and StHub"
> spec for: #'pharo6.x' version: '6.0'.     "still open version branch from Pharo 6 using git and GitHub"
> spec for: #'pharo7.x' version: '7.0'.     "still open version branch from Pharo 7 using git and GitHub"
> ------------------------------------------------------------------------------------------------------------
>
> This allows me to maintain the differences between the Pharo 6 and Pharo 7 version by using the two distinguished branches
> and backport from the "pharo7" branch easily to the "pharo6" branch if necessary.
>
> As no tagging with explicit versioning is involved here the branch for each Pharo version is always open for new
> additions/future fixes.
>
> The first model is close to what one is used to from the past: having reproducible fixed tagged versions referenced
> from the ConfigurationOf...  
>
> The second model fits better if you provide packages that you would like to maintain for several Pharo versions from 6.0
> onwards. I now also use it to maintain "QuickAccess", "OSWindows", "OSUnix", ... and others.
>
> Hope this helps a little bit. If not just ask.
>
> Have fun
> T.
>
>
>> Gesendet: Montag, 17. Dezember 2018 um 17:16 Uhr
>> Von: "Sven Van Caekenberghe" <[hidden email]>
>> An: "Pharo Development List" <[hidden email]>
>> Betreff: [Pharo-dev] Catalog Entries
>>
>> 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
>>
>>
>>
>

> On 17 Dec 2018, at 20:18, Torsten Bergmann <[hidden email]> 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....

> On Dec 17, 2018, at 1:16 PM, Sven Van Caekenberghe <[hidden email]> 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
>
>

> On 18 Dec 2018, at 12:05, Guillermo Polito <[hidden email]> wrote:
>
>
>
> On Tue, Dec 18, 2018 at 12:00 PM Sven Van Caekenberghe <[hidden email]> wrote:
>
>
> > On 17 Dec 2018, at 20:18, Torsten Bergmann <[hidden email]> 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.

> On 18 Dec 2018, at 12:48, Torsten Bergmann <[hidden email]> 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.

> Gesendet: Dienstag, 18. Dezember 2018 um 12:54 Uhr
> Von: "Sven Van Caekenberghe" <[hidden email]>
> An: "Pharo Development List" <[hidden email]>
> Betreff: Re: [Pharo-dev] Catalog Entries
>
>
>
> > On 18 Dec 2018, at 12:48, Torsten Bergmann <[hidden email]> 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.
>
>
>

> On 18 Dec 2018, at 13:45, Torsten Bergmann <[hidden email]> wrote:
>
> 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" <[hidden email]>
>> An: "Pharo Development List" <[hidden email]>
>> Betreff: Re: [Pharo-dev] Catalog Entries
>>
>>
>>
>>> On 18 Dec 2018, at 12:48, Torsten Bergmann <[hidden email]> 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.
>>
>>
>>
>

> On 18 Dec 2018, at 13:45, Ben Coman <[hidden email]> wrote:
>
>
>
> On Tue, 18 Dec 2018 at 19:12, Sven Van Caekenberghe <[hidden email]> 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 <[hidden email]> wrote:
> >
> >
> >
> > On Tue, Dec 18, 2018 at 12:00 PM Sven Van Caekenberghe <[hidden email]> wrote:
> >
> >
> > > On 17 Dec 2018, at 20:18, Torsten Bergmann <[hidden email]> 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.

> On 18 Dec 2018, at 14:23, Ben Coman <[hidden email]> wrote:
>
>
>
> On Tue, 18 Dec 2018 at 21:01, Esteban Maringolo <[hidden email]> wrote:
> El mar., 18 dic. 2018 a las 9:53, Sven Van Caekenberghe
> (<[hidden email]>) escribió:
> >
> > So let us agree on the best name then, to minimise confusion going forward.
> >
> > I am not sure I would go for camel case, git is typically lowercase (or so it feels), I agree 'release' should be part of the name, so
> >
> > last-release
> > latest-release
> > lastRelease
> > latestRelease
>
> Following "gittish" conventions, IMO `latest-release` would be the
> proper name because "last" suggests me there won't be more releases
> afterwards.
>
> Good point. +1.
>
> But I wonder if moving tags is really a good idea.  I've not practical experience with it
> but reading section "If the tag is edited on the server, but the local one is old"
>     http://blog.iqandreas.com/git/how-to-move-tags/
> it seems potentially complicated.
>
> Whereas if latest-release was a branch, after you version tag your release you could do...
> $ git checkout latest-release
> $ git merge tagversion
> $ git push
>
> And side benefit, latest-release would show up in the github > Insights > Network view
> to easily inspect what changes have been made since latest-release.
>
> cheers -ben

> On 18 Dec 2018, at 16:29, Torsten Bergmann <[hidden email]> wrote:
>
> Ben wrote
>> "If the tag is edited on the server, but the local one is old"
>
> Yes - there could be an issue with this "tag moving" approach if the server is not checked
> for new tags / moved tags and the version from the local repo cache is loaded - because
> you might load an outdated while the server already has a newer "latest-release".
>
> When I think a second time I guess what Sven wants could maybe also be achieved with another
> model:
>
> - having the "master" branch for development and tagged releases 1.0, 2.0, 3.0 and so on
> - having a second "latest-release" branch where the current latest tag from master is just pulled/merged in
>   Anytime you make a new release version in master you just pull it into this "latest-release" branch
>
> This has several benefits:
>
> - you can use the same stable load expression with stable URL: github://svenvc/ztimestamp:latest-release
> - you just tag in master as usual
> - when a new release was tagged in master you just switch to the "latest-release" branch, pull from master
>   and push to github (easier than tag moving)
> - the graph ("Insights" -> "Network") shows you if you already pulled the latest tagged version from master
>   into the "latest-release" branch and also shows you how far ahead you are with master in case of further
>   development
>
> Also when the latest release has some trouble but your master development is not yet ready for a full new version
> you can hot-fix it in the "latest-release" branch to help people. Later when you are ready with another full new
> version you will have the branches resynched then anyway.
>
> I'm not sure if this model also has some drawbacks - but as it looks now this seems a better option...
>
> Bye
> T.
>
>
>
>
>
>