GlorpSQLite Github release management
Hi all, So GlorpSQLite works on Pharo 5 and 6, but not yet on Pharo 7. Currently, I have the following: https://github.com/PierceNg/glorp https://github.com/PierceNg/glorp-sqlite3 Which are forks of these: https://github.com/pharo-rdbms/glorp https://github.com/pharo-rdbms/glorp-sqlite3 I'm thinking to create a release, say, v1.0, for the current known working GlorpSQLite combo for Pharo 5 and 6 in my repos, then, ... create a branch for Pharo 7? Then turn the branch into release v2.0 when ready? I do all of these actions in my repo, and through pull requests to upstream, Git will take care of synchronizing across the forks? Does the above sound workable? Is there a better approach? Pierce, Git noob
Hi Pierce, On Fri, 12 Oct 2018 at 06:21, Pierce Ng <pierce@samadhiweb.com> wrote:
Hi all,
So GlorpSQLite works on Pharo 5 and 6, but not yet on Pharo 7.
I've been using GlorpSQLite in Pharo 7 since development started. It is loaded from another package's baseline as: spec baseline: 'GlorpSQLite' with: [ spec repository: 'github://pharo-rdbms/glorp-sqlite3' ]. I have some patches for date and time handling which I load on top (and should really submit as a patch), but I don't think these are Pharo 7 related.
Currently, I have the following:
https://github.com/PierceNg/glorp https://github.com/PierceNg/glorp-sqlite3
Which are forks of these:
https://github.com/pharo-rdbms/glorp https://github.com/pharo-rdbms/glorp-sqlite3
I'll take a look.
I'm thinking to create a release, say, v1.0, for the current known working GlorpSQLite combo for Pharo 5 and 6 in my repos, then, ... create a branch for Pharo 7? Then turn the branch into release v2.0 when ready? I do all of these actions in my repo, and through pull requests to upstream, Git will take care of synchronizing across the forks?
I'm not a git expert either, but I suspect the branches will need to be created in the main repository. The modifications can then be applied to the appropriate branch as a PR.
Does the above sound workable? Is there a better approach?
Pierce, Git noob
On Fri, 12 Oct 2018 at 14:04, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi Pierce,
On Fri, 12 Oct 2018 at 06:21, Pierce Ng <pierce@samadhiweb.com> wrote:
Hi all,
So GlorpSQLite works on Pharo 5 and 6, but not yet on Pharo 7.
I've been using GlorpSQLite in Pharo 7 since development started. It is loaded from another package's baseline as:
spec baseline: 'GlorpSQLite' with: [ spec repository: 'github://pharo-rdbms/glorp-sqlite3' ].
I have some patches for date and time handling which I load on top (and should really submit as a patch), but I don't think these are Pharo 7 related.
Currently, I have the following:
https://github.com/PierceNg/glorp https://github.com/PierceNg/glorp-sqlite3
Which are forks of these:
https://github.com/pharo-rdbms/glorp https://github.com/pharo-rdbms/glorp-sqlite3
I'll take a look.
I'm thinking to create a release, say, v1.0, for the current known working GlorpSQLite combo for Pharo 5 and 6 in my repos, then, ... create a branch for Pharo 7? Then turn the branch into release v2.0 when ready?
If there is no change to the GlorpSQLite API, but just the implementation (i.e. on Pharo 7), then v1.1 seems a better choice of version number.
I do all of these actions in my repo, and through pull requests
to upstream, Git will take care of synchronizing across the forks?
Note that git branches are simply pointers to a particular commit hash. There is no computational link between the "branch name" in your repo and the "branch name" in the target repo. On github you can create a PR from any repo/branch to any other repo/branch that exists. As Alistar indicated, if you want a particular "branch name" in the target repo, it needs to have already been created there. Then you can submit a PR to it from any branch in your repo.
I'm not a git expert either, but I suspect the branches will need to be created in the main repository. The modifications can then be applied to the appropriate branch as a PR.
btw, for a reproducability of a "release" version, my understanding is that in the canonical repo, tags are better than branches because tags are permanently tied to a particular while branches move. (However I've not direct experience with this) cheers -ben
On Sat, Oct 13, 2018 at 09:51:53AM +0800, Ben Coman wrote:
Note that git branches are simply pointers to a particular commit hash. There is no computational link between the "branch name" in your repo and the "branch name" in the target repo.
Thanks Ben and Alistair. I'll experiment and write up whatever I find out. Pierce
participants (3)
-
Alistair Grant -
Ben Coman -
Pierce Ng