- Pharo-dev - lists.pharo.org

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

Re: [Pharo-dev] OSSubprocess use

by Thierry Goubier

Le 23/01/2016 17:17, Mariano Martinez Peck a Ã©crit : > > > On Sat, Jan 23, 2016 at 12:42 PM, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@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. > Yes, I know, I implemented part of that support into gitfiletree urls (commit ids and tags don't work with git clone, of course). > Yes, and not only tags, what everything (commits, branches, etc). See > this post: > http://blog.yuriy.tymch.uk/2015/07/pharo-and-github-versioning-revision-2.h… > > This is the supported pattern: > > github://<username>/<projectname>[:<branch>|<tag>|<SHA>][/<path>] I was thinking of the wildcard support Dale implemented ;) Thierry > :) > > -- > Mariano > http://marianopeck.wordpress.com

Jan. 23, 2016

Re: [Pharo-dev] OSSubprocess use

by Mariano Martinez Peck

On Sat, Jan 23, 2016 at 12:42 PM, 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. > > Yes, and not only tags, what everything (commits, branches, etc). See this post: http://blog.yuriy.tymch.uk/2015/07/pharo-and-github-versioning-revision-2.h… This is the supported pattern: github://<username>/<projectname>[:<branch>|<tag>|<SHA>][/<path>] :) -- Mariano http://marianopeck.wordpress.com

Jan. 23, 2016

Re: [Pharo-dev] OSSubprocess use

by Eliot Miranda

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.

Jan. 23, 2016

Re: [Pharo-dev] OSSubprocess use

by Thierry Goubier

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

Jan. 23, 2016

Re: [Pharo-dev] Add to Package

by Mariano Martinez Peck

On Sat, Jan 23, 2016 at 12:02 PM, stepharo <stepharo(a)free.fr> wrote: > > > Le 23/1/16 15:14, Esteban A. Maringolo a Ã©crit : > >> 2016-01-23 4:48 GMT-03:00 stepharo <stepharo(a)free.fr>: >> >>> Hi >>> >>> in MC add to package should use a FastList because the logic right now is >>> really stupid. >>> >> I would also add the "add repo" to the package, with a list of the >> recently used repos. Or add the repo to a multiple number of packages. >> > > That too :) > >> >> Also...previously, when you typed in the text input, it would hide/filter out/gray the none matching ones and only let highlighted the ones matching what you typed. That doesn't seem to work anymore :( -- Mariano http://marianopeck.wordpress.com

Jan. 23, 2016