On Fri, 12 Oct 2018 at 14:04, Alistair Grant <akgrant0...@gmail.com> wrote:
> Hi Pierce, > > On Fri, 12 Oct 2018 at 06:21, Pierce Ng <pie...@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
