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" <s...@stfx.eu> > An: "Pharo Development List" <pharo-dev@lists.pharo.org> > 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 > > >
