On Fri, Jan 22, 2016 at 11:50 AM, Thierry Goubier <[email protected] > 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 ... 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? 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) ? > > (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. > Thierry > > * There is a bit of code to write, of course, but most of it is reusing > what already exists inside Skip github and GitFileTree. > > 2016-01-22 14:33 GMT+01:00 Mariano Martinez Peck <[email protected]>: > >> Hi guys, >> >> Let's say there is a project which is being build with metadata-less >> GitFileTree. There is a BaselineOf and a ConfigurationOf which work >> correctly. And ConfigurationOf can perfectly have fixed "versions" that >> could be, at some point, integrated in Pharo. >> >> Let's say I release version 1.0 which is INTEGRATED inside Pharo. When >> Pharo image is build, it uses ConfigurationOfMyApp to load the code and so >> there will be NO history of versions (cypress.1). >> >> Now, as Pharo goes on, there may be changes to that project as part of >> refactors or whatever that happens in-image. So in one months from now, >> Pharo may have a "newer" code than the originally released 1.0. Let's say >> that for the package MyAppPackage were only 3 commits in those 2 months. >> >> At the same time, I have continue working with my project, and I am ready >> to publish 1.1. >> >> Question is.... how do I bring Pharo changes to my own place? >> >> 1) Fetching (from Pharo repo) and pushing to my GitFileTree only the >> versions during those 2 months? I doubt this will work as crappy >> Monticello numbers could have collisions, right? >> >> 2) Doing a poor man diff and cherry picking changes from Pharo repo and >> manually apply them to my own repo? In this case, the "3 commits" of those >> 2 months will be lost as from git history version. >> >> Is there a project doing this?? I know QualityAssistant is close, but he >> does not use metadata-less GitFileTree I think...so I am not sure. >> >> Thoughts? >> >> Thanks! >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > -- Mariano http://marianopeck.wordpress.com
