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