Versioning #16

New Issue

emma · 2023-12-26T11:24:23-07:00

emma commented

2023-12-26 11:24:23 -07:00

How do we want to do Bonsai versioning?

emma added the

enhancement

question

labels 2023-12-26 11:24:24 -07:00

emma self-assigned this 2023-12-26 11:24:24 -07:00

silt was assigned by emma

2023-12-26 11:24:24 -07:00

trinity was assigned by emma

2023-12-26 11:24:24 -07:00

trinity commented

2023-12-26 13:57:31 -07:00

I lean towards releasing the nightly at the end of each month as version YYYYMM, e.g. the first release would be 202312. That way we never have to think about it.

Otherwise maybe release.major.minor, with minor reflecting bugfixes, major reflecting utilities added + utilities removed since release.0.0, and release being 0 until the full functionality offered by POSIX section 1 is released, then 1 until some big breaking change (whatever that may be). This is complicated though.

I lean towards releasing the nightly at the end of each month as version YYYYMM, e.g. the first release would be 202312. That way we never have to think about it. Otherwise maybe release.major.minor, with minor reflecting bugfixes, major reflecting utilities added + utilities removed since release.0.0, and release being 0 until the full functionality offered by POSIX section 1 is released, then 1 until some big breaking change (whatever that may be). This is complicated though.

emma commented

2023-12-26 14:14:31 -07:00

so semver for most of the time? im cool with that. what i mean though is are we versioning each tool or the whole project or both?

i’m not sure we need to do nightlies, i’m not too interested in distributing binaries so people can just go to the main branch and build it. we should make sure the main branch always builds.

so semver for most of the time? im cool with that. what i mean though is are we versioning each tool or the whole project or both? i’m not sure we need to do nightlies, i’m not too interested in distributing binaries so people can just go to the main branch and build it. we should make sure the main branch always builds.

trinity commented

2023-12-26 17:34:41 -07:00

I mean the nightly not as a binary release but as a tarball of the current repository tree (more like a git branch/tag/whatever). So you can git clone $bonsai_coreutils; cd coreutils; git checkout 202402; make true if you so desire.

Versioning each tool sounds tricky and complicated. Best the whole tree and let package maintainers figure it out.

I mean the nightly not as a binary release but as a tarball of the current repository tree (more like a git branch/tag/whatever). So you can `git clone $bonsai_coreutils; cd coreutils; git checkout 202402; make true` if you so desire. Versioning each tool sounds tricky and complicated. Best the whole tree and let package maintainers figure it out.

emma commented

2023-12-27 14:21:52 -07:00

what do you think of x.x.x-nightly?

trinity commented

2023-12-28 16:18:20 -07:00

There are currently seven utilities in the tree. Following my previous decimal scheme, it could be something like

0.7.0-rel
0.7.1-20231228 (a nightly before 0.7.1)
0.7.1-rel

But I think it would be much simpler to do YYYYMM.

There are currently seven utilities in the tree. Following my previous decimal scheme, it could be something like - 0.7.0-rel - 0.7.1-20231228 (a nightly before 0.7.1) - 0.7.1-rel But I think it would be much simpler to do YYYYMM.

emma commented

2024-02-07 20:42:56 -07:00

For now, let’s just do semver and worry about nightlies later if it becomes a thing we really want to do.

emma closed this issue

2024-04-26 21:42:21 -06:00

Sign in to join this conversation.