2016-01-22 17:22 GMT+01:00 Mariano Martinez Peck <marianopeck@gmail.com>:
On Fri, Jan 22, 2016 at 11:50 AM, Thierry Goubier < 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.
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. 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.
In either case, just to confirm, we do NOT do fetch/push because of the versions problem right? I mean...it will be either me or another guy (the guy that created the issue), but one of us will finally end up putting the "changes" (not a MC version) in the upstream whatever ways are taking for that (via PR or whatever) ?
Yes, but the push will be a MC version anyway? I don't understand; using git means that you can just save and push versions, and git will determine what the diff is...
(Was I clear with that description? Feel free to ask or correct me :))
Now, about the package versions. There is an issue with metadata-less mode and a few quirks about the way Metacello check versions to upgrade packages, and the issue is open. Two ways forward are possible: David Allouche pointed one by saying ordering between versions (without checking the numbers) can be resolved by checking if one is an ancestor of the other... and the other is that, with Skip work on the github api, it becomes possible(*) to retrieve the version info from github without git and avoid those -Cypress.1.
OK that would very cool.
Yes, I think so too. Thierry