Re: [Pharo-dev] Catalog Entries
Hi Sven, On Tue, 18 Dec 2018 at 12:55, Sven Van Caekenberghe wrote: > > 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. I think your understanding of master is different from mine. master should never be the next release candidate, it is only ever the latest GA code. In that case, you can use master to mean "the latest GA version". If you want release candidates, they should be branches off development (or tags). If you want to support multiple versions, e.g. be able to release a 4.1 after 5.0 has been released, then each version should be branched off master (at the GA commit for that version). If you want to know where a named GA version is (and there won't be further updates), it is a tag on the master branch. Cheers, Alistair
Re: [Pharo-dev] Huge Critiques Area in Calypso in Pharo 7
Hi Petr. Setting would be nice. I did not know about it in Nautilus вт, 18 дек. 2018 г. в 14:44, Petr Fischer via Pharo-dev < pharo-dev@lists.pharo.org>: > I have that feeling too - critiques pane is annoying + occupying too much > place - what about showing critiques inline only (in the line nubers and > breakpoint markers left pane)? > > This choice existed for the old Nautilus browser - but I can't find it for > Calypso. > > pf > > > I am seeing a huge (multiline, ~ 5 to 7 lines) high 'critiques' area at > the bottom of Calypso browsers in Pharo 7 (dl today), see screenshot: > > > > > > Why is that ? I can't resize it to be smaller. > > On a smaller screen this takes up way too much space. > > Can't we have a widget to remove/collapse that area ? Not a setting. > > > > Sven > > > >
Re: [Pharo-dev] Huge Critiques Area in Calypso in Pharo 7
Hi Sven. I did little change in Pharo https://github.com/pharo-project/pharo/pull/2096. The best would be to have floating/docking layout of such panes like in other IDEs. Probably easy to do in Bloc but not in Morphic пн, 17 дек. 2018 г. в 18:52, Sven Van Caekenberghe : > Thanks, Denis, for the swift reply. > What is the solution, though ? > What do you think should happen ? > Make the constant smaller, like the height of 1 row ? > > > On 17 Dec 2018, at 18:42, Denis Kudriashov wrote: > > > > Hi Sven. > > > > I checked problem and found following method: > > > > FTTableMorph >> minHeight > > ^ 100 > > > > It prevents full critiques widget to be small. > > > > There is probably a bug in morphic which does not set up this "correct" > extent by default. In my case when I browse your method in fresh image only > three rows are visible in critiques view. But as soon as I start resizing > this pane it becomes bigger and unminimizable. > > > > пн, 17 дек. 2018 г. в 17:14, Sven Van Caekenberghe : > > I am seeing a huge (multiline, ~ 5 to 7 lines) high 'critiques' area at > the bottom of Calypso browsers in Pharo 7 (dl today), see screenshot: > > > > > > Why is that ? I can't resize it to be smaller. > > On a smaller screen this takes up way too much space. > > Can't we have a widget to remove/collapse that area ? Not a setting. > > > > Sven > > > > >
Re: [Pharo-dev] Catalog Entries
> On 18 Dec 2018, at 17:34, Ben Coman wrote:
>
> To understand for future reference, just curious what you ended up doing.
> At https://github.com/svenvc/ztimestamp/releases
> I see the v24 tag is commit ee31f06
>
> but at https://github.com/svenvc/ztimestamp/network
> I see the latest-release branch is commit b18dfdf
>
> It looks like you v24 of ConfigurationOfZTimestamp was committed after v24
> tag was created.
> Intuitively I'd expect the them to be the same commit. Was there something
> impediment to doing that
> or you have a different idea?
Well, I did make a mistake, I committed the change to the ConfigurationOf on
the latest-release branch, so I had to PR and merge to master.
But apart from that it was a chicken-egg problem (as far as I can see), that
won't happen in the future, then it will be just the merge of the release tag
into the latest-release branch, as you described earlier.
We'll see, learning along the way.
> cheers -ben
>
> On Tue, 18 Dec 2018 at 23:42, Sven Van Caekenberghe wrote:
> 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 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.
> >
> >
> >
> >
> >
> >
>
>
Re: [Pharo-dev] Catalog Entries
To understand for future reference, just curious what you ended up doing.
At https://github.com/svenvc/ztimestamp/releases
I see the v24 tag is commit ee31f06
but at https://github.com/svenvc/ztimestamp/network
I see the latest-release branch is commit b18dfdf
It looks like you v24 of ConfigurationOfZTimestamp was committed after v24
tag was created.
Intuitively I'd expect the them to be the same commit. Was there something
impediment to doing that
or you have a different idea?
cheers -ben
On Tue, 18 Dec 2018 at 23:42, Sven Van Caekenberghe wrote:
> 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 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.
> >
> >
> >
> >
> >
> >
>
>
>
Re: [Pharo-dev] Catalog Entries
> On 18 Dec 2018, at 16:41, Sven Van Caekenberghe wrote: > > I will extend the ConfigurationOf to refer to it for Pharo 6.1 and 7 https://github.com/svenvc/ztimestamp/commit/2eadc5d1730ca24d2a946b7b7bbb6b195c8759c8 is a commit that changes ConfigurationOfZTimestamp by adding a version 24 that refers to the latest-release branch on git for pharo 6.1 and up. I copied that Config into the repos of 60 and 70. We'll see what that gives with respect to the Catalog.
Re: [Pharo-dev] Catalog Entries
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 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.
>
>
>
>
>
>
Re: [Pharo-dev] Catalog Entries
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.
[Pharo-dev] [Pharo 7.0] Build #58: 22797 deprecated file does not exist should be moved to deprecated70 package
There is a new Pharo build available! The status of the build #58 was: FAILURE. The Pull Request #2092 was integrated: "22797 deprecated file does not exist should be moved to deprecated70 package" Pull request url: https://github.com/pharo-project/pharo/pull/2092 Issue Url: https://pharo.fogbugz.com/f/cases/22797 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo7.0/58/
Re: [Pharo-dev] possible QA rule - cascading to class
Hi Ben, On Tue, 18 Dec 2018 at 14:52, Ben Coman wrote: > In case someone close to managing the QA rules is interested... on discord > it > was suggested that this form of cascading might be a trap for newcomers. > >x := MyClass new; foo > > I've never seen similar in practice, so it might make a good QA rule. > It currently raises "Sends unknown message to global" > but I'd guess a more specific message that actually mentions > "cascading" could be possible. > > I was the one who brought it up on Discord, being it seems the forever newbie with Pharo... It's worse if you have a class-side method. The error is "Instance of X class did not understand #foo", which is evil to newbies because an "instance of [a] class" seems like it should be an object, and I *did* have a message of type "foo" defined. Here's the real case with a screenshot: [image: image.png] Cheers, Christopher > cheers -ben > >
[Pharo-dev] possible QA rule - cascading to class
In case someone close to managing the QA rules is interested... on discord it was suggested that this form of cascading might be a trap for newcomers. x := MyClass new; foo I've never seen similar in practice, so it might make a good QA rule. It currently raises "Sends unknown message to global" but I'd guess a more specific message that actually mentions "cascading" could be possible. cheers -ben
Re: [Pharo-dev] Catalog Entries
> On 18 Dec 2018, at 14:23, Ben Coman wrote: > > > > On Tue, 18 Dec 2018 at 21:01, Esteban Maringolo wrote: > El mar., 18 dic. 2018 a las 9:53, Sven Van Caekenberghe > () 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
Re: [Pharo-dev] Catalog Entries
On Tue, 18 Dec 2018 at 21:01, Esteban Maringolo wrote: > El mar., 18 dic. 2018 a las 9:53, Sven Van Caekenberghe > () 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
Re: [Pharo-dev] Catalog Entries
JOKING:"lastRelease" is fine, there is no release afterwards anymore as it is completed by 100% ;) SERIOUS: "latest-release" seems appropriate
Re: [Pharo-dev] Catalog Entries
El mar., 18 dic. 2018 a las 9:53, Sven Van Caekenberghe () 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
Re: [Pharo-dev] Catalog Entries
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 wrote:
>
>
>
> On Tue, 18 Dec 2018 at 19:12, Sven Van Caekenberghe 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
> > wrote:
> >
> >
> >
> > On Tue, Dec 18, 2018 at 12:00 PM Sven Van Caekenberghe wrote:
> >
> >
> > > On 17 Dec 2018, at 20:18, Torsten Bergmann 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
> > >
> > >
> > > 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.
Re: [Pharo-dev] Catalog Entries
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 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" >> An: "Pharo Development List" >> Betreff: Re: [Pharo-dev] Catalog Entries >> >> >> >>> On 18 Dec 2018, at 12:48, Torsten Bergmann 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. >> >> >> >
Re: [Pharo-dev] Catalog Entries
On Tue, 18 Dec 2018 at 19:12, Sven Van Caekenberghe 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
> wrote:
> >
> >
> >
> > On Tue, Dec 18, 2018 at 12:00 PM Sven Van Caekenberghe
> wrote:
> >
> >
> > > On 17 Dec 2018, at 20:18, Torsten Bergmann 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
> > >
> > >
> > > 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.
>
>
>
Re: [Pharo-dev] Catalog Entries
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" > An: "Pharo Development List" > Betreff: Re: [Pharo-dev] Catalog Entries > > > > > On 18 Dec 2018, at 12:48, Torsten Bergmann 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. > > >
[Pharo-dev] [Pharo 7.0] Build #57: 22780 Fix uncategorized classes in MonticelloGUI
There is a new Pharo build available! The status of the build #57 was: FAILURE. The Pull Request #2078 was integrated: "22780 Fix uncategorized classes in MonticelloGUI" Pull request url: https://github.com/pharo-project/pharo/pull/2078 Issue Url: https://pharo.fogbugz.com/f/cases/22780 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo7.0/57/
Re: [Pharo-dev] Catalog Entries
> On 18 Dec 2018, at 12:48, Torsten Bergmann 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.
Re: [Pharo-dev] Catalog Entries
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.
[Pharo-dev] [Pharo 7.0] Build #56: 22760 RBRefactoryClassChange should define #isAbstract with true
There is a new Pharo build available! The status of the build #56 was: FAILURE. The Pull Request #2084 was integrated: "22760 RBRefactoryClassChange should define #isAbstract with true" Pull request url: https://github.com/pharo-project/pharo/pull/2084 Issue Url: https://pharo.fogbugz.com/f/cases/22760 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo7.0/56/
Re: [Pharo-dev] Catalog Entries
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 wrote:
>
>
>
> On Tue, Dec 18, 2018 at 12:00 PM Sven Van Caekenberghe wrote:
>
>
> > On 17 Dec 2018, at 20:18, Torsten Bergmann 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
> >
> >
> > 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.
Re: [Pharo-dev] Catalog Entries
--- Begin Message --- 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 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 > > --- End Message ---
Re: [Pharo-dev] Catalog Entries
On Tue, Dec 18, 2018 at 12:00 PM Sven Van Caekenberghe wrote:
>
>
> > On 17 Dec 2018, at 20:18, Torsten Bergmann 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
> >
> >
> > 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.
Re: [Pharo-dev] Catalog Entries
> On 17 Dec 2018, at 20:18, Torsten Bergmann 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
>
>
> 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.
[Pharo-dev] [Pharo 7.0] Build #55: 22801 Small cleanups in TRBProgramNodeVisitor
There is a new Pharo build available! The status of the build #55 was: SUCCESS. The Pull Request #2093 was integrated: "22801 Small cleanups in TRBProgramNodeVisitor" Pull request url: https://github.com/pharo-project/pharo/pull/2093 Issue Url: https://pharo.fogbugz.com/f/cases/22801 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo7.0/55/
Re: [Pharo-dev] Catalog Entries
On Tue, 18 Dec 2018 at 03:19, Torsten Bergmann 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. >
Re: [Pharo-dev] Huge Critiques Area in Calypso in Pharo 7
--- Begin Message --- I have that feeling too - critiques pane is annoying + occupying too much place - what about showing critiques inline only (in the line nubers and breakpoint markers left pane)? This choice existed for the old Nautilus browser - but I can't find it for Calypso. pf > I am seeing a huge (multiline, ~ 5 to 7 lines) high 'critiques' area at the > bottom of Calypso browsers in Pharo 7 (dl today), see screenshot: > > > Why is that ? I can't resize it to be smaller. > On a smaller screen this takes up way too much space. > Can't we have a widget to remove/collapse that area ? Not a setting. > > Sven > --- End Message ---
