January 2016 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core] d56ab8: 50541

by GitHub

Branch: refs/heads/5.0 Home: https://github.com/pharo-project/pharo-core Commit: d56ab8399d8756c9f671332e11c5dde1c1dc92ec https://github.com/pharo-project/pharo-core/commit/d56ab8399d8756c9f671332e… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2016-01-24 (Sun, 24 Jan 2016) Changed paths: M Growl.package/GrowlMorph.class/class/settings/growlSettingsOn_.st R NautilusCommon.package/extension/RGClassDefinition/instance/definition.st A Ring-Core-Kernel.package/RGBehaviorDefinition.class/instance/filein%2Fout/definition.st M Rubric.package/RubTextAreaExamples.class/class/examples/profileSourcesFileViewing.st M Rubric.package/RubTextAreaExamples.class/class/private/show_while_.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50540.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - scripts/script50541.st R ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50540.st A ScriptLoader50.package/ScriptLoader.class/instance/pharo - updates/update50541.st M ScriptLoader50.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st M Tool-ExternalBrowser.package/ExternalBrowser.class/instance/structure accessing/showClassDefinition.st Log Message: ----------- 50541 17404 ExternalBrowser can not show meta class definition https://pharo.fogbugz.com/f/cases/17404 17443 RubTextAreaExamples>>#show:while: should not use #displayWorldSafely https://pharo.fogbugz.com/f/cases/17443 17457 Change Growl setting name to PopupNotifier https://pharo.fogbugz.com/f/cases/17457 http://files.pharo.org/image/50/50541.zip

Jan. 24, 2016

Re: [Pharo-dev] OSSubprocess use

by Thierry Goubier

Le 23/01/2016 19:23, Eliot Miranda a Ã©crit : > Hi Thierry, > >> On Jan 23, 2016, at 8:38 AM, Thierry Goubier >> <thierry.goubier(a)gmail.com> wrote: >> >> Hi Eliot, >> >> Le 23/01/2016 17:04, Eliot Miranda a Ã©crit : >>> Hi Both, Hi Dale, >>> >>>> On Jan 23, 2016, at 7:42 AM, Thierry Goubier >>>> <thierry.goubier(a)gmail.com> wrote: >>>> >>>> Le 23/01/2016 15:44, Mariano Martinez Peck a Ã©crit : >>>>> Hi Thierry, >>>>> >>>>> The Metacello answer here would be "it's up to you" hahahaha. >>>>> I don't have a strong opinion. Most of the times I am in the >>>>> similar situation, I tend to use fixed versions when the >>>>> projects are really coupled and one cannot work without the >>>>> other. And use #stable when they are less coupled and I would >>>>> not die if that dependency is broken for some time until >>>>> fixed. >>>>> >>>>> What would be the problem of using #stable? That I may >>>>> release new versions which may break the user API, or I may >>>>> introduce bugs that I didn't discover before, etc etc. It >>>>> won't be fun if I update GitFileTree and suddenly I cannot >>>>> commit anymore. But at the same time, you don't expect a user >>>>> to be updating GitFileTree in his image. In addition, you >>>>> have a CI that will tell you immediately if the build fail or >>>>> your tests failed. >>>>> >>>>> If you ask me, I think I would use fixed versions. Then, >>>>> whenever I release a new version, you give it a try, you test >>>>> it, you try it in the CI, etc. If everything seems to work, >>>>> then I would update your conf and point to new version. >>>> >>>> Yes. What is interesting is I can just target the baseline of >>>> OSSubprocess in that case, using that url >>>> >>>> github://marianopeck/OSSubprocess:v0.2.0/repository >>>> >>>> which is convenient. >>>> >>>> Thierry >>> >>> Maybe soon enough we can find a way of integrating CI server >>> test results for specific packages with Metacello and talk not >>> about #stable, but #greenest. Green means tests have passed, but >>> i think the connotation of green=young is common too, no? (viÃ±o >>> verde). This doesn't protect against API changes, when the tests >>> get changed to match the new API, but that implies versioning the >>> API separately from the package so one can ask for #greenest >>> #api=1.23. >> >> Well, if you take a Travis / Github integration and you fetch from >> branch 1.23, then you should only merge into that branch with a >> pull request if the tests are green. Moreover, with Metacello, >> baselines and branches you allways target the newest version; as >> long as your CI ensure that tests are green before merging into >> public/stable branches, then that already works. >> >> The branch methodology would look like that, then: >> >> - one branch for each stable / long lived version with garanteed >> API compatibility - v1.1 - one tag for each released version, when >> merged in their right overall branch - v1.1.0, v1.1.1, v1.1.2, >> v1.1.3 (inside branch v1.1) - development branches for the main >> work. - and an integrated CI like travis so that no merge can be >> done in a release branch without having everything green. >> >> Like that, if you target v1.1, you'll get the latest green version >> on API 1.1 :) > > Listening to Stephan I think the key point is "with the minimum > amount of manual work". Of course I can use the process above. But > if what the tests were to run were specified in code or as package > metadata, and the ci to run the tests was "available as a service" > without my having to configure, then I wouldn't need to manually > manage the process of only committing to the public version when the > tests were green; the system would do that for me. I certainly agree with that "minimum amount of manual work", and this is why I'm looking for the less friction setup: one that doesn't require me to update a few configurations in addition to merging and checking my integration tests. However, I would prefer to have, when releasing, a decision where I decide to push something, when all tests are green, and not automatically. As, for example, Dale has setup the FileTree repository, then I can commit and push on separate branches, let CI check those, and merge when I'm sure to a stable branch (when everything is green). Now, having nightly builds automatically the latest green one... I guess that can be done. > The only thing I'd have to do as a designer is name or version the > API if it needed to evolve. But the setup you describe is a bleeding edge type of things, on which some commits or pushes just fail the CI tests. So I'm not sure I'd like to be a user of that. Thierry

Jan. 23, 2016

Re: [Pharo-dev] How to manage GitFileTree and being integrated in-image (QualityAssistant example?)

by Thierry Goubier

Le 23/01/2016 19:00, Mariano Martinez Peck a Ã©crit : > > > On Fri, Jan 22, 2016 at 1:39 PM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > > > 2016-01-22 17:22 GMT+01:00 Mariano Martinez Peck > <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>>: > > > > On Fri, Jan 22, 2016 at 11:50 AM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> > wrote: > > Hi Mariano, > > this is a common question for external projects integrated > inside the Pharo image. And we have an issue with version > numbers, but let's try to keep that separate. > > Fixes to the code of external projects integrated inside > Pharo should be done upstream (on the external project > itself), not in the Pharo image. This is what is currently > happening with the GT tools, NeoJSON, Zinc, and probably a > few more. So, as a maintainer of such a projects in github, > say, you can ask people to create issues on your project, > pull requests and the like, and this is the only way bugs > found in Pharo in your release project should be corrected. > Then, everytime a new version of the Pharo image is built, a > version of your project is integrated; and you can add an > issue to update your project to a newer version inside Pharo. > > > Well, that covers A PART of the problem. If someone finds a bug > or whatever in MY project, then your workflow sounds perfect. > Now...consider internal refactors of Pharo that affects multiple > projects. For example few months ago, someone changes all > senders of #instVarNames to #instanceVariabls (or something like > that...I don't remember the exact change but something like > that). As part of those senders, there was Fuel. So when that > SLICE was integrated (with multiple packages as dependencies of > the SLICE), Fuel package was one of them. > > So what should be the path in this case: > > 1) Ask the poor guy that make the slice to also do the fork, git > clone, install gitfiletree, commit, push and make PR ... > > > Hum, takes about: > - 1 click or two on github for the fork > - 1 click on the configuration manager for gitfiletree > - 4 lines of metacello for remote clone + repository > - 3 clicks and a bit of text for the commit in the fork > - two clicks for the push to github > - 2 or 3 clicks for the pull request > > Soon (or even already now?), Skip Github code would allow that > without git/gitfiletree. But in github world, you would need a fork > anyway. > > > > Indeed. I have to admit that at the beginning I also thought it was > quit a pain. But now that I have done that many times, I can confirm > it's quite really easy. What is nice in there is that you have a clear way to open upstream to contributions (pull requests and issues) and manage those. In practice, I'd guess contributors will do the fork only once. But they will have to learn to keep it up to date with the upstream project :) > 2) Myself (as the developer of the tool) get notified when my > package gets changed and then, I take care of doing a diff and > manaully "port" the fix to my upstream project? > > > Probably this one. Technically, it is easy to: get the latest image; > get the gitfiletree repository; create a branch at the previous > stable version of the project; save the changed packages into that > branch; then decide (git merge?) those changes into either a new > stable version or on a development branch. Git will take care of the > difference between your new stuff and the stuff changed in Pharo, > and merge properly unless both sides have changed the same method / > line in a method. > > > That's a very cool path! The idea of making a branch from the last tag > version is great. Then you are at the normal branch/merge behavior. Yes. Especially since in such a change, you want to merge in two places: a successor to the tag (a v1.1.3 if it was v1.1.2) to release a new stable with the change for integration in the Pharo image, and a merge into your development branch. > I don't expect this sort of changes to occur very often. As you say, > this is a particular use case, with a large number of packages > changed, so I would consider that a rare occurrence for which I > don't have to specially optimize the process, just to have it > possible. Smaller fixes should be done the 1) way. > > > Fully agree. Thierry

Jan. 23, 2016

Re: [Pharo-dev] OSSubprocess use

by Eliot Miranda

Hi Thierry, > On Jan 23, 2016, at 8:38 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Hi Eliot, > > Le 23/01/2016 17:04, Eliot Miranda a Ã©crit : >> Hi Both, Hi Dale, >> >>> On Jan 23, 2016, at 7:42 AM, Thierry Goubier >>> <thierry.goubier(a)gmail.com> wrote: >>> >>> Le 23/01/2016 15:44, Mariano Martinez Peck a Ã©crit : >>>> Hi Thierry, >>>> >>>> The Metacello answer here would be "it's up to you" hahahaha. I >>>> don't have a strong opinion. Most of the times I am in the >>>> similar situation, I tend to use fixed versions when the projects >>>> are really coupled and one cannot work without the other. And use >>>> #stable when they are less coupled and I would not die if that >>>> dependency is broken for some time until fixed. >>>> >>>> What would be the problem of using #stable? That I may release >>>> new versions which may break the user API, or I may introduce >>>> bugs that I didn't discover before, etc etc. It won't be fun if I >>>> update GitFileTree and suddenly I cannot commit anymore. But at >>>> the same time, you don't expect a user to be updating GitFileTree >>>> in his image. In addition, you have a CI that will tell you >>>> immediately if the build fail or your tests failed. >>>> >>>> If you ask me, I think I would use fixed versions. Then, whenever >>>> I release a new version, you give it a try, you test it, you try >>>> it in the CI, etc. If everything seems to work, then I would >>>> update your conf and point to new version. >>> >>> Yes. What is interesting is I can just target the baseline of >>> OSSubprocess in that case, using that url >>> >>> github://marianopeck/OSSubprocess:v0.2.0/repository >>> >>> which is convenient. >>> >>> Thierry >> >> Maybe soon enough we can find a way of integrating CI server test >> results for specific packages with Metacello and talk not about >> #stable, but #greenest. Green means tests have passed, but i think >> the connotation of green=young is common too, no? (viÃ±o verde). >> This doesn't protect against API changes, when the tests get changed >> to match the new API, but that implies versioning the API separately >> from the package so one can ask for #greenest #api=1.23. > > Well, if you take a Travis / Github integration and you fetch from branch 1.23, then you should only merge into that branch with a pull request if the tests are green. Moreover, with Metacello, baselines and branches you allways target the newest version; as long as your CI ensure that tests are green before merging into public/stable branches, then that already works. > > The branch methodology would look like that, then: > > - one branch for each stable / long lived version with garanteed API compatibility > - v1.1 > - one tag for each released version, when merged in their right overall branch > - v1.1.0, v1.1.1, v1.1.2, v1.1.3 (inside branch v1.1) > - development branches for the main work. > - and an integrated CI like travis so that no merge can be done in a release branch without having everything green. > > Like that, if you target v1.1, you'll get the latest green version on API 1.1 :) Listening to Stephan I think the key point is "with the minimum amount of manual work". Of course I can use the process above. But if what the tests were to run were specified in code or as package metadata, and the ci to run the tests was "available as a service" without my having to configure, then I wouldn't need to manually manage the process of only committing to the public version when the tests were green; the system would do that for me. The only thing I'd have to do as a designer is name or version the API if it needed to evolve. > > Thierry >

Jan. 23, 2016

Re: [Pharo-dev] How to manage GitFileTree and being integrated in-image (QualityAssistant example?)

by Mariano Martinez Peck

On Fri, Jan 22, 2016 at 1:39 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > > 2016-01-22 17:22 GMT+01:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >> >> >> On Fri, Jan 22, 2016 at 11:50 AM, Thierry Goubier < >> thierry.goubier(a)gmail.com> wrote: >> >>> Hi Mariano, >>> >>> this is a common question for external projects integrated inside the >>> Pharo image. And we have an issue with version numbers, but let's try to >>> keep that separate. >>> >>> Fixes to the code of external projects integrated inside Pharo should be >>> done upstream (on the external project itself), not in the Pharo image. >>> This is what is currently happening with the GT tools, NeoJSON, Zinc, and >>> probably a few more. So, as a maintainer of such a projects in github, say, >>> you can ask people to create issues on your project, pull requests and the >>> like, and this is the only way bugs found in Pharo in your release project >>> should be corrected. Then, everytime a new version of the Pharo image is >>> built, a version of your project is integrated; and you can add an issue to >>> update your project to a newer version inside Pharo. >>> >> >> Well, that covers A PART of the problem. If someone finds a bug or >> whatever in MY project, then your workflow sounds perfect. >> Now...consider internal refactors of Pharo that affects multiple >> projects. For example few months ago, someone changes all senders of >> #instVarNames to #instanceVariabls (or something like that...I don't >> remember the exact change but something like that). As part of those >> senders, there was Fuel. So when that SLICE was integrated (with multiple >> packages as dependencies of the SLICE), Fuel package was one of them. >> >> So what should be the path in this case: >> >> 1) Ask the poor guy that make the slice to also do the fork, git clone, >> install gitfiletree, commit, push and make PR ... >> > > Hum, takes about: > - 1 click or two on github for the fork > - 1 click on the configuration manager for gitfiletree > - 4 lines of metacello for remote clone + repository > - 3 clicks and a bit of text for the commit in the fork > - two clicks for the push to github > - 2 or 3 clicks for the pull request > > Soon (or even already now?), Skip Github code would allow that without > git/gitfiletree. But in github world, you would need a fork anyway. > Indeed. I have to admit that at the beginning I also thought it was quit a pain. But now that I have done that many times, I can confirm it's quite really easy. > > >> 2) Myself (as the developer of the tool) get notified when my package >> gets changed and then, I take care of doing a diff and manaully "port" the >> fix to my upstream project? >> > > Probably this one. Technically, it is easy to: get the latest image; get > the gitfiletree repository; create a branch at the previous stable version > of the project; save the changed packages into that branch; then decide > (git merge?) those changes into either a new stable version or on a > development branch. Git will take care of the difference between your new > stuff and the stuff changed in Pharo, and merge properly unless both sides > have changed the same method / line in a method. > > That's a very cool path! The idea of making a branch from the last tag version is great. Then you are at the normal branch/merge behavior. > I don't expect this sort of changes to occur very often. As you say, this > is a particular use case, with a large number of packages changed, so I > would consider that a rare occurrence for which I don't have to specially > optimize the process, just to have it possible. Smaller fixes should be > done the 1) way. > > Fully agree. Mariano http://marianopeck.wordpress.com

Jan. 23, 2016

Re: [Pharo-dev] OSSubprocess use

by Thierry Goubier

Le 23/01/2016 18:42, Gabriel Cotelli a Ã©crit : > Well.. If you follow the semantic versioning guidelines > <http://semver.org/> the dependency can be done in metacello with the > new scripting API like this: > > github://marianopeck/OSSubprocess:v1.?/repository Yes, this is what I was looking for. But, thinking of it, if I do a v1 branch where I merge all the v1.x versions as I release them, then github://marianopeck/OSSubprocess:v1/repository is enough to retrieve the latest subversion. I'm just looking to see what is the simplest / less error prone setup; to avoid the errors made updating a configuration by hand. If you release say v1.5 and have to update a configuration in the meta repo by hand with that number, then part of your release testing suppose you also run that configuration to check you haven't introduced errors. Thierry > and this will match the newest sub-version, in this way there's no need > to update dependent projects unless a major version is released (because > this implies breaking changes in the public API). > > > > On Sat, Jan 23, 2016 at 11:44 AM, Mariano Martinez Peck > <marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote: > > Hi Thierry, > > The Metacello answer here would be "it's up to you" hahahaha. I > don't have a strong opinion. Most of the times I am in the similar > situation, I tend to use fixed versions when the projects are really > coupled and one cannot work without the other. And use #stable when > they are less coupled and I would not die if that dependency is > broken for some time until fixed. > > What would be the problem of using #stable? That I may release new > versions which may break the user API, or I may introduce bugs that > I didn't discover before, etc etc. It won't be fun if I update > GitFileTree and suddenly I cannot commit anymore. But at the same > time, you don't expect a user to be updating GitFileTree in his > image. In addition, you have a CI that will tell you immediately if > the build fail or your tests failed. > > If you ask me, I think I would use fixed versions. Then, whenever I > release a new version, you give it a try, you test it, you try it in > the CI, etc. If everything seems to work, then I would update your > conf and point to new version. > > Cheers, > > On Sat, Jan 23, 2016 at 9:09 AM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > > Hi, > > I'm looking at OSSubprocess use as a requirement for GitFileTree > and I wonder if it is wise to list the dependency on > OSSubprocess #stable or to set to a specific version (v0.2)? > > Thanks, > > Thierry > > > > > -- > Mariano > http://marianopeck.wordpress.com > >

Jan. 23, 2016

Re: [Pharo-dev] OSSubprocess use

by Gabriel Cotelli

Well.. If you follow the semantic versioning guidelines <http://semver.org/> the dependency can be done in metacello with the new scripting API like this: github://marianopeck/OSSubprocess:v1.?/repository and this will match the newest sub-version, in this way there's no need to update dependent projects unless a major version is released (because this implies breaking changes in the public API). On Sat, Jan 23, 2016 at 11:44 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > Hi Thierry, > > The Metacello answer here would be "it's up to you" hahahaha. I don't have > a strong opinion. Most of the times I am in the similar situation, I tend > to use fixed versions when the projects are really coupled and one cannot > work without the other. And use #stable when they are less coupled and I > would not die if that dependency is broken for some time until fixed. > > What would be the problem of using #stable? That I may release new > versions which may break the user API, or I may introduce bugs that I > didn't discover before, etc etc. It won't be fun if I update GitFileTree > and suddenly I cannot commit anymore. But at the same time, you don't > expect a user to be updating GitFileTree in his image. In addition, you > have a CI that will tell you immediately if the build fail or your tests > failed. > > If you ask me, I think I would use fixed versions. Then, whenever I > release a new version, you give it a try, you test it, you try it in the > CI, etc. If everything seems to work, then I would update your conf and > point to new version. > > Cheers, > > > On Sat, Jan 23, 2016 at 9:09 AM, Thierry Goubier < > thierry.goubier(a)gmail.com> wrote: > >> Hi, >> >> I'm looking at OSSubprocess use as a requirement for GitFileTree and I >> wonder if it is wise to list the dependency on OSSubprocess #stable or to >> set to a specific version (v0.2)? >> >> Thanks, >> >> Thierry >> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Jan. 23, 2016

Re: [Pharo-dev] Use cases for methods with optional parameters

by Hilaire

Yes, sometime we are writing 2 or 3 methods just to handle default values for some arguments. It is not a big deal, just annoying. New feature, that may be useful is namespace. No idea about its implication however. Thanks -- Dr. Geo http://drgeo.eu

Jan. 23, 2016

Symbolic version management with Metacello) was: OSSubprocess use

by Stephan Eggermont

We want to use Metacello to manage smalltalk dependencies in a way that results in working software using a minimum amount of manual work. At the moment there are several ways in which Metacello is used, some of which result in more work and instability than others. An inherent conflict in managing these dependencies is the level of repeatability that is wanted and achievable, vs. the amount of manual work needed. On the one hand we would like perfect repeatability. That needs an exact description of the order in which specific versions of packages were loaded in a specific image. In Metacello, we can achieve this by making sure all package versions are fixed and the dependencies are fixed to numeric versions. The problem with this is that that not necessarily results in working software. There are several reasons for this: - Metacello only manages the smalltalk level dependencies. It does not take into account changes in the vm necessitating image-level changes or operating system and library changes. - The image itself is not fully managed with Metacello (yet). Bug fixes made after the creation of the Metacello version might be needed for the software to work. - Bugs might have been found and fixed in dependencies. In the situation of a top-level configuration, i.e. one that no other configuration depends on, this might be acceptable. Metacello dependencies are defined one-directional. A configuration knows on which configuration it depends, not which configurations depend on it. Configurations that are published should therefore always be regarded as possibly being used by others, and not only top-level. If we consider the situation where others (B) are depending on configurations (A) that are written like this, then the situation gets worse: - B might need an update because it is affected by an issue that does not affect A. - B might need a different load ordering, e.g. need to only partially load dependencies of A, then something itself and then the other dependencies of A. Nevertheless, sometimes we need near-perfect repeatability. For that, a snapshot of all loaded packages provides a reasonable alternative to a Metacello configuration version. On the other hand the least amount of manual updates results from always depending on #development or #stable versions of dependencies. This results in the following problems: - If the API of a dependency changes, the configuration might break silently. - Projects might be slow to promote versions from #bleedingEdge to #development to #stable, resulting in a slow uptake of improvements. For configurations of simple packages that have an API that is very stable or only expands, depending on #stable can be appropriate. From a modularity point of view, a configuration should be specific on the packages in its own span of control, and as generous as possible in what it accepts from its dependencies. In that way a high cohesion and low coupling is achieved. We can achieve that by defining symbolic versions that reflect observable change in behaviour. If we make changes that should not affect users of the configuration, we create a new numeric version and update the symbolic version in place to use this new version. By default we only depend on these symbolic versions. Stephan

Jan. 23, 2016

Re: [Pharo-dev] OSSubprocess use

by Thierry Goubier

Hi Eliot, Le 23/01/2016 17:04, Eliot Miranda a Ã©crit : > Hi Both, Hi Dale, > >> On Jan 23, 2016, at 7:42 AM, Thierry Goubier >> <thierry.goubier(a)gmail.com> wrote: >> >> Le 23/01/2016 15:44, Mariano Martinez Peck a Ã©crit : >>> Hi Thierry, >>> >>> The Metacello answer here would be "it's up to you" hahahaha. I >>> don't have a strong opinion. Most of the times I am in the >>> similar situation, I tend to use fixed versions when the projects >>> are really coupled and one cannot work without the other. And use >>> #stable when they are less coupled and I would not die if that >>> dependency is broken for some time until fixed. >>> >>> What would be the problem of using #stable? That I may release >>> new versions which may break the user API, or I may introduce >>> bugs that I didn't discover before, etc etc. It won't be fun if I >>> update GitFileTree and suddenly I cannot commit anymore. But at >>> the same time, you don't expect a user to be updating GitFileTree >>> in his image. In addition, you have a CI that will tell you >>> immediately if the build fail or your tests failed. >>> >>> If you ask me, I think I would use fixed versions. Then, whenever >>> I release a new version, you give it a try, you test it, you try >>> it in the CI, etc. If everything seems to work, then I would >>> update your conf and point to new version. >> >> Yes. What is interesting is I can just target the baseline of >> OSSubprocess in that case, using that url >> >> github://marianopeck/OSSubprocess:v0.2.0/repository >> >> which is convenient. >> >> Thierry > > Maybe soon enough we can find a way of integrating CI server test > results for specific packages with Metacello and talk not about > #stable, but #greenest. Green means tests have passed, but i think > the connotation of green=young is common too, no? (viÃ±o verde). > This doesn't protect against API changes, when the tests get changed > to match the new API, but that implies versioning the API separately > from the package so one can ask for #greenest #api=1.23. Well, if you take a Travis / Github integration and you fetch from branch 1.23, then you should only merge into that branch with a pull request if the tests are green. Moreover, with Metacello, baselines and branches you allways target the newest version; as long as your CI ensure that tests are green before merging into public/stable branches, then that already works. The branch methodology would look like that, then: - one branch for each stable / long lived version with garanteed API compatibility - v1.1 - one tag for each released version, when merged in their right overall branch - v1.1.0, v1.1.1, v1.1.2, v1.1.3 (inside branch v1.1) - development branches for the main work. - and an integrated CI like travis so that no merge can be done in a release branch without having everything green. Like that, if you target v1.1, you'll get the latest green version on API 1.1 :) Thierry

Jan. 23, 2016