[Pharo-dev] [Pharo 7.0] Build #63: 22811 Fix comment in ExternalBrowser
There is a new Pharo build available! The status of the build #63 was: SUCCESS. The Pull Request #2102 was integrated: "22811 Fix comment in ExternalBrowser" Pull request url: https://github.com/pharo-project/pharo/pull/2102 Issue Url: https://pharo.fogbugz.com/f/cases/22811 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo7.0/63/
[Pharo-dev] [Pharo 7.0] Build #62: 22812 Clean the ImageCleaner
There is a new Pharo build available! The status of the build #62 was: SUCCESS. The Pull Request #2103 was integrated: "22812 Clean the ImageCleaner" Pull request url: https://github.com/pharo-project/pharo/pull/2103 Issue Url: https://pharo.fogbugz.com/f/cases/22812 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo7.0/62/
[Pharo-dev] [Pharo 7.0] Build #61: 22809 Cleanup MethodFinderTest and related sample classes
There is a new Pharo build available! The status of the build #61 was: FAILURE. The Pull Request #2101 was integrated: "22809 Cleanup MethodFinderTest and related sample classes" Pull request url: https://github.com/pharo-project/pharo/pull/2101 Issue Url: https://pharo.fogbugz.com/f/cases/22809 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo7.0/61/
Re: [Pharo-dev] Catalog Entries
> On 19 Dec 2018, at 10:58, Alistair Grant wrote: > > Hi Sven, > > On Wed, 19 Dec 2018 at 10:46, Sven Van Caekenberghe wrote: >> >> >> >>> On 19 Dec 2018, at 08:50, Alistair Grant wrote: >>> >>> 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. >> >> 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? Yes, that is the question ;-) >> I also want to make things as simple as possible. > > :-) > > Cheers, > Alistair
[Pharo-dev] [Pharo 7.0] Build #60: 22777 ManifestMonticello and ManifestRingMonticello should be tagged with "Manifest"
There is a new Pharo build available! The status of the build #60 was: SUCCESS. The Pull Request #2076 was integrated: "22777 ManifestMonticello and ManifestRingMonticello should be tagged with "Manifest"" Pull request url: https://github.com/pharo-project/pharo/pull/2076 Issue Url: https://pharo.fogbugz.com/f/cases/22777 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%20and%20branch%20Pipeline/job/Pharo7.0/60/
Re: [Pharo-dev] Catalog Entries
Hi Sven, On Wed, 19 Dec 2018 at 10:46, Sven Van Caekenberghe wrote: > > > > > On 19 Dec 2018, at 08:50, Alistair Grant wrote: > > > > 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. > > 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
[Pharo-dev] [Pharo 7.0] Build #59: 22806 Small cleanups in EmbeddedFreeTypeFontInstallerTest
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%20and%20branch%20Pipeline/job/Pharo7.0/59/
Re: [Pharo-dev] Catalog Entries
> On 19 Dec 2018, at 08:50, Alistair Grant wrote: > > 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. 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
