Smalltalk › Pharo › Pharo Smalltalk Users

GlorpSQLite Github release management

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Pierce Ng-3

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

alistairgrant

Re: GlorpSQLite Github release management

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
>

Ben Coman

Re: GlorpSQLite Github release management

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

Pierce Ng-3

Re: GlorpSQLite Github release management

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