Catalog Entries

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Catalog Entries

Sven Van Caekenberghe-2
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


Reply | Threaded
Open this post in threaded view
|

Re: Catalog Entries

Torsten Bergmann
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
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Catalog Entries

Sven Van Caekenberghe-2
Hi Torsten,

Thanks for the clear explication, I think I will most probably go for scenario 1, but it is good to at least know about scenario 2.

I'll sure come back if I cannot get this working on my own.

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
>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Catalog Entries

Ben Coman
In reply to this post by Torsten Bergmann


On Tue, 18 Dec 2018 at 03:19, Torsten Bergmann <[hidden email]> wrote:

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.

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.

In the past I've contemplated that this form might be a good way to manage cross-platform code,
but also having a "master" and merge from there into each "pharo6" , "pharo7" , "squeakN" platform-branch if/when 
they get some git tools.  The workflow might then be that users of a particular platform 
push can issue a PR to that particular platform-branch to make the changes easy to see,
and integrate into "master" if useful. 

cheers -ben 

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.

 
Reply | Threaded
Open this post in threaded view
|

Re: Catalog Entries

Sven Van Caekenberghe-2
In reply to this post by Torsten Bergmann


> 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.



Reply | Threaded
Open this post in threaded view
|

Re: Catalog Entries

Guillermo Polito


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.
Reply | Threaded
Open this post in threaded view
|

Re: Catalog Entries

Pharo Smalltalk Developers mailing list
In reply to this post by Sven Van Caekenberghe-2
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 <[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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Catalog Entries

Sven Van Caekenberghe-2
In reply to this post by Guillermo Polito
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 <[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.


Reply | Threaded
Open this post in threaded view
|

Re: Catalog Entries

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.

Reply | Threaded
Open this post in threaded view
|

Re: Catalog Entries

Sven Van Caekenberghe-2


> 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.


Reply | Threaded
Open this post in threaded view
|

Re: Catalog Entries

Ben Coman
In reply to this post by Sven Van Caekenberghe-2


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.


Reply | Threaded
Open this post in threaded view
|

Re: Catalog Entries

Torsten Bergmann
In reply to this post by Sven Van Caekenberghe-2
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.
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Catalog Entries

Sven Van Caekenberghe-2
Yes that is what I want, I hoped it already existed, by yes we can use a tag that we move with each release.

> 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.
>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Catalog Entries

Sven Van Caekenberghe-2
In reply to this post by Ben Coman
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

What say you ?

> 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.


Reply | Threaded
Open this post in threaded view
|

Re: Catalog Entries

Esteban A. Maringolo
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.

Regards,

Esteban A. Maringolo

Reply | Threaded
Open this post in threaded view
|

Re: Catalog Entries

Torsten Bergmann
JOKING:    "lastRelease" is fine, there is no release afterwards anymore as it is completed by 100% ;)

SERIOUS:   "latest-release" seems appropriate


Reply | Threaded
Open this post in threaded view
|

Re: Catalog Entries

Ben Coman
In reply to this post by Esteban A. Maringolo


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" 
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
Reply | Threaded
Open this post in threaded view
|

Re: Catalog Entries

Sven Van Caekenberghe-2


> 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

interesting.

since both a branch and a moving tag look the same from the reference standpoint, this could be considered an implementation detail, the repo maintainer could switch later on, while the URL would remain github://svenvc/ztimestamp:latest-release




Reply | Threaded
Open this post in threaded view
|

Re: Catalog Entries

Torsten Bergmann
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.






Reply | Threaded
Open this post in threaded view
|

Re: Catalog Entries

Sven Van Caekenberghe-2
Ben, Torsten,

I decided to go for the branch option,

https://github.com/svenvc/ztimestamp/tree/latest-release

I will extend the ConfigurationOf to refer to it for Pharo 6.1 and 7

Thanks for all the help.

> 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.
>
>
>
>
>
>


12