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 <[email protected]> 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" <[email protected]> >> An: "Pharo Development List" <[email protected]> >> 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 >> >> >> >
