December 2018 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Catalog Entries

by Alistair Grant

Hi Sven, On Wed, 19 Dec 2018 at 10:46, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > On 19 Dec 2018, at 08:50, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > Hi Sven, > > > > On Tue, 18 Dec 2018 at 12:55, Sven Van Caekenberghe <sven(a)stfx.eu> 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. > > I don't think/believe there is only one right way to use git, that is part of its power. Agreed, and I can see how you read my reply that way, but I didn't mean to imply that "this is the one and only right way to do it". > In our eco system, with #stable and #bleedingEdge / #development versions of ConfigurationsOf, it is my experience that very few people test before something is released. Hence the only way to get feedback is to release. Only if something has proven itself to be stable for some time can it receive a release tag, IMHO. OK, so what I understand you're try to achieve is to have a "released" version and a "released and better tested" version. Doesn't this run the same risk of people just sticking to the "released and better tested" version, so the "released" version never gets the additional testing that's desired? > I also want to make things as simple as possible. :-) Cheers, Alistair

Dec. 19, 2018

[Pharo 7.0] Build #59: 22806 Small cleanups in EmbeddedFreeTypeFontInstallerTest

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #59 was: SUCCESS. The Pull Request #2099 was integrated: "22806 Small cleanups in EmbeddedFreeTypeFontInstallerTest" Pull request url: https://github.com/pharo-project/pharo/pull/2099 Issue Url: https://pharo.fogbugz.com/f/cases/22806 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 19, 2018

Re: [Pharo-dev] Catalog Entries

by Sven Van Caekenberghe

> On 19 Dec 2018, at 08:50, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Sven, > > On Tue, 18 Dec 2018 at 12:55, Sven Van Caekenberghe <sven(a)stfx.eu> 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. I don't think/believe there is only one right way to use git, that is part of its power. In our eco system, with #stable and #bleedingEdge / #development versions of ConfigurationsOf, it is my experience that very few people test before something is released. Hence the only way to get feedback is to release. Only if something has proven itself to be stable for some time can it receive a release tag, IMHO. I also want to make things as simple as possible. > Cheers, > Alistair

Dec. 19, 2018

Re: [Pharo-dev] Catalog Entries

by Alistair Grant

Hi Sven, On Tue, 18 Dec 2018 at 12:55, Sven Van Caekenberghe <sven(a)stfx.eu> 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

Dec. 19, 2018

Re: [Pharo-dev] Huge Critiques Area in Calypso in Pharo 7

by Denis Kudriashov

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(a)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 > > > >

Dec. 18, 2018

Re: [Pharo-dev] Huge Critiques Area in Calypso in Pharo 7

by Denis Kudriashov

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 <sven(a)stfx.eu>: > 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 <dionisiydk(a)gmail.com> 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 <sven(a)stfx.eu>: > > 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: > > > > <Screenshot 2018-12-17 at 17.19.35.png> > > 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 > > > > >

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Sven Van Caekenberghe

> On 18 Dec 2018, at 17:34, Ben Coman <btc(a)openinworld.com> 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 <sven(a)stfx.eu> 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 <astares(a)gmx.de> 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. > > > > > > > > > > > > > >

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Ben Coman

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 <sven(a)stfx.eu> 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 <astares(a)gmx.de> 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. > > > > > > > > > > > > > > >

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Sven Van Caekenberghe

> On 18 Dec 2018, at 16:41, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > I will extend the ConfigurationOf to refer to it for Pharo 6.1 and 7 https://github.com/svenvc/ztimestamp/commit/2eadc5d1730ca24d2a946b7b7bbb6b1… 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.

Dec. 18, 2018

Re: [Pharo-dev] Catalog Entries

by Sven Van Caekenberghe

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 <astares(a)gmx.de> 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. > > > > > >

Dec. 18, 2018