GlorpSQLite Github release management

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

GlorpSQLite Github release management

Pierce Ng-3
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

Reply | Threaded
Open this post in threaded view
|

Re: GlorpSQLite Github release management

Alistair Grant
Hi Pierce,

On Fri, 12 Oct 2018 at 06:21, Pierce Ng <[hidden email]> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: GlorpSQLite Github release management

Ben Coman


On Fri, 12 Oct 2018 at 14:04, Alistair Grant <[hidden email]> wrote:
Hi Pierce,

On Fri, 12 Oct 2018 at 06:21, Pierce Ng <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: GlorpSQLite Github release management

Pierce Ng-3
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