Next release

[Waldek Hebisch]

I would like to do release in next days. ATM build with clisp
is broken and I would like to include the fix (but this fix
is still subject to testing).

For other changes I prepared addition to release notes,
preliminary version is at:

http://www.math.uni.wroc.pl/~hebisch/fricas/ug_note.diff

Please consider now trunk frozen for release.

--
Waldek Hebisch

[Qian Yun]

Hi Waldek,

I'd like to put Windows and macOS binary on the GitHub
release page. Do you agree with that?

- Qian

[Waldek Hebisch]

On Sun, Jun 19, 2022 at 08:53:20AM +0800, Qian Yun wrote:
> Hi Waldek,
>
> I'd like to put Windows and macOS binary on the GitHub
> release page. Do you agree with that?
>
> - Qian

Yes, very good. Just one little thing: binaries should
be build from released sources, so that people who
build from source tarball should get the same thing as
people who fetch binaries.

--
Waldek Hebisch

[Qian Yun]

Thank you! The binaries are built by CI automatically,
so after you tag the release, you can download the
binary from GitHub. (You must log into GitHub to download
the CI artifacts. And then unzip it to get the dmg
binary for macOS and the zip binary for windows.
And then rename the commit sha to version number.)
Or I can do that for you and modify the GitHub release
page myself.

I'll tweak the CI a little bit to make the binaries
a little more user friendly.

- Qian

[Waldek Hebisch]

On Sun, Jun 19, 2022 at 10:02:43PM +0800, Qian Yun wrote:
> Thank you! The binaries are built by CI automatically,
> so after you tag the release, you can download the
> binary from GitHub. (You must log into GitHub to download
> the CI artifacts. And then unzip it to get the dmg
> binary for macOS and the zip binary for windows.
> And then rename the commit sha to version number.)
> Or I can do that for you and modify the GitHub release
> page myself.
>
> I'll tweak the CI a little bit to make the binaries
> a little more user friendly.

One thing to check: to build HyperDoc pages from git sources
we need access to X server, either actual one or 'xvfb-run'.
Release tarball contains pregenerated pages, so this is not
a problem when building from tarball.

--
Waldek Hebisch

[Qian Yun]

I have disabled X11 support for this version.
(Not confident about X11 on macOS right now.
HyperDoc is extremely sluggish on my macOS VM.
Let's see how many users use this binary, and
if there are users to request this and help
to test it.)

You are right, this is a valid issue.

Maybe for next release, I'll improve the CI to use
the full tarball for release packaging.

- Qian

[Ralf Hemmecke]

> Or I can do that for you and modify the GitHub release
> page myself.

Oh. That sounds like one could modify what the release tarballs are.
In that case, I would, of course be interested to additionally put a
linux-binary there that includes hunchentoot.

That may, however take a bit longer, since I'll be away from the net and
I do not think I get things in shape before.

Ralf

[Qian Yun]

Hi Waldek,

Shall we remove ".gitignore .gitattributes .github" in
src/scripts/mkdist.sh as well?

- Qian

On 6/19/22 00:12, Waldek Hebisch wrote:

[Waldek Hebisch]

On Sun, Jun 19, 2022 at 11:03:11PM +0800, Qian Yun wrote:
> I have disabled X11 support for this version.
> (Not confident about X11 on macOS right now.
> HyperDoc is extremely sluggish on my macOS VM.
> Let's see how many users use this binary, and
> if there are users to request this and help
> to test it.)
>
> You are right, this is a valid issue.
>
> Maybe for next release, I'll improve the CI to use
> the full tarball for release packaging.

OK, that is better then nothing. I have now
created release tarbals: source, i386 and amd64
Linux. IIUC Github automatically created snapshot of
repository and put in src* archives.

Now it is time to create other tarballs/zips.
Note: release is done from branch 1.3.8. The
only difference compared to trunk is that
FRICASsys on release branch prints

Version: FriCAS 1.3.8

while trunk prints:

Version: FriCAS 2021-03-06

There is extra things in release: it contains help files
which are copied from previous release.

I am not sure if Github allows you to put things on release,
if yes please add them. I very much prefer to that you
create tarballs as you understand better what is in CI.
Also, I have no way to test on Mac and almost no way to
test on Windows.

--
Waldek Hebisch

[Qian Yun]

Hi Waldek,

GitHub allows me to modify the release page to add new binaries.

A few questions:

http://fricas.sourceforge.net/doc/INSTALL-bin.txt stills mentions 1.3.7.
Shall we put that file into git as well? Some other parts need
updating as well.

Now the tag name and branch name is the same. It is a little
inconvenient to checkout them. Can you rename the branch name
to something else?

- Qian

[Waldek Hebisch]

On Wed, Jun 22, 2022 at 07:46:03AM +0800, Qian Yun wrote:
> Hi Waldek,
>
> GitHub allows me to modify the release page to add new binaries.
>
> A few questions:
>
> http://fricas.sourceforge.net/doc/INSTALL-bin.txt stills mentions 1.3.7.
> Shall we put that file into git as well? Some other parts need
> updating as well.

I update this at each release. Keeping it in version control is
almost no gain. ATM I am waiting for all binaries, this is
part that changes for each release. And of course, we need some
info about how to install new binaries.

Basically I want to officially announce release once all binaries
and documents are in place (I do not want to change Notes-1.3.8.txt
after release as this may cause confusion, and Notes-1.3.8.txt
contains names of binaries).

> Now the tag name and branch name is the same. It is a little
> inconvenient to checkout them. Can you rename the branch name
> to something else?

Tag is pure Github nonsense, apparently it does not allow
making relase without a tag. IMO, to minimize confusion it
is best to keep them the same. Concerning checkout IIUC
canonical procedure is:

git clone
git checkout

and it seems to work fine. What problem do you see?

--
Waldek Hebisch

[Waldek Hebisch]

On Tue, Jun 21, 2022 at 09:27:01PM +0800, Qian Yun wrote:
> Hi Waldek,
>
> Shall we remove ".gitignore .gitattributes .github" in
> src/scripts/mkdist.sh as well?

For the next release we probably should change cleaning pattern
to

rm -rf .git*

but for the current one I did not consider this to be critical.

--
Waldek Hebisch

[Qian Yun]

On 6/22/22 08:18, Waldek Hebisch wrote:
> On Wed, Jun 22, 2022 at 07:46:03AM +0800, Qian Yun wrote:
>> Hi Waldek,
>>
>> GitHub allows me to modify the release page to add new binaries.
>>
>> A few questions:
>>
>> http://fricas.sourceforge.net/doc/INSTALL-bin.txt stills mentions 1.3.7.
>> Shall we put that file into git as well? Some other parts need
>> updating as well.
>
> I update this at each release. Keeping it in version control is
> almost no gain. ATM I am waiting for all binaries, this is
> part that changes for each release. And of course, we need some
> info about how to install new binaries.
>
> Basically I want to officially announce release once all binaries
> and documents are in place (I do not want to change Notes-1.3.8.txt
> after release as this may cause confusion, and Notes-1.3.8.txt
> contains names of binaries).

I have uploaded macOS/windows binaries. And I add a few sentences
at the end of the release page. Feel free to add them to
INSTALL-bin.txt.

>> Now the tag name and branch name is the same. It is a little
>> inconvenient to checkout them. Can you rename the branch name
>> to something else?
>
> Tag is pure Github nonsense, apparently it does not allow
> making relase without a tag. IMO, to minimize confusion it
> is best to keep them the same. Concerning checkout IIUC
> canonical procedure is:
>
> git clone
> git checkout
>
> and it seems to work fine. What problem do you see?
>

Tag and branch are the same name, you will get
warning: refname '1.3.8' is ambiguous.
And when you do checkout, it defaults to tag instead of branch.

- Qian

[Waldek Hebisch]

On Wed, Jun 22, 2022 at 08:44:00AM +0800, Qian Yun wrote:
>
>
> On 6/22/22 08:18, Waldek Hebisch wrote:
> >On Wed, Jun 22, 2022 at 07:46:03AM +0800, Qian Yun wrote:
> >>Hi Waldek,
> >>
> >>GitHub allows me to modify the release page to add new binaries.
> >>
> >>A few questions:
> >>
> >>http://fricas.sourceforge.net/doc/INSTALL-bin.txt stills mentions 1.3.7.
> >>Shall we put that file into git as well? Some other parts need
> >>updating as well.
> >
> >I update this at each release. Keeping it in version control is
> >almost no gain. ATM I am waiting for all binaries, this is
> >part that changes for each release. And of course, we need some
> >info about how to install new binaries.
> >
> >Basically I want to officially announce release once all binaries
> >and documents are in place (I do not want to change Notes-1.3.8.txt
> >after release as this may cause confusion, and Notes-1.3.8.txt
> >contains names of binaries).
>
> I have uploaded macOS/windows binaries. And I add a few sentences
> at the end of the release page. Feel free to add them to
> INSTALL-bin.txt.

I have copied them to SourceForge and added them to INSTALL-bin.txt.
I have also created Notes-1.3.8.txt. I have put main source tarball
to Github under wrong name (dot instead of dash), I will correct
to later.

> >>Now the tag name and branch name is the same. It is a little
> >>inconvenient to checkout them. Can you rename the branch name
> >>to something else?
> >
> >Tag is pure Github nonsense, apparently it does not allow
> >making relase without a tag. IMO, to minimize confusion it
> >is best to keep them the same. Concerning checkout IIUC
> >canonical procedure is:
> >
> >git clone
> >git checkout
> >
> >and it seems to work fine. What problem do you see?
> >
>
> Tag and branch are the same name, you will get
> warning: refname '1.3.8' is ambiguous.
> And when you do checkout, it defaults to tag instead of branch.

Well, branch and tag really point to the same sources, so is
this a problem?

--
Waldek Hebisch

[Qian Yun]

On 6/22/22 15:11, Waldek Hebisch wrote:
>>> Tag is pure Github nonsense, apparently it does not allow
>>> making relase without a tag. IMO, to minimize confusion it
>>> is best to keep them the same. Concerning checkout IIUC
>>> canonical procedure is:
>>>
>>> git clone
>>> git checkout
>>>
>>> and it seems to work fine. What problem do you see?
>>>
>>
>> Tag and branch are the same name, you will get
>> warning: refname '1.3.8' is ambiguous.
>> And when you do checkout, it defaults to tag instead of branch.
>
> Well, branch and tag really point to the same sources, so is
> this a problem?
>

If we add more commits to 1.3.8 branch, then branch 1.3.8 and
tag 1.3.8 will point to different places.

(If we never make commits to 1.3.8 branch, then why create this branch?
We can make release on master branch then.)

- Qian

[Ralf Hemmecke]

> If we add more commits to 1.3.8 branch, then branch 1.3.8 and
> tag 1.3.8 will point to different places.

Clearly there could be errors after creating the release branch so there
would be several commits that appear on the release branch and on the
master branch. That's a bit annoying, but may happen. Nevertheless, once
the release happens and the release branch is tagged, there shouldn't be
any changes made to the release branch. In that sense branch an tag will
point to the same sha1 and one could actually delete the branch (the
commits will not dissappear, since there is a tag at the top of the
release branch).

> (If we never make commits to 1.3.8 branch, then why create this branch?
> We can make release on master branch then.)

Actually, we could start another development strategy.


*---*---*--- ... ---*------- devel branch
/ \
*----*-----------------------*----- master brach
1.3.7 1.3.8

Development happens on a devel branch. A release is then just a merge of
devel branch into the master branch and a tag on the master branch.
(Or above we call devel:=master and master:=release.)

As far as I understand Waldek created the 1.3.8 branch only to have an
extra commit that sets the version number. That is similar to the above
only that 1.3.7 is not a parent of 1.3.8.

I guess the simplest solution now would be to remove the branch names
1.3.7 and 1.3.8. They are the only "ambiguous" names. For all the other
tags there is no branch name.

Ralf

[Waldek Hebisch]

On Sat, Jun 18, 2022 at 04:12:45PM +0000, Waldek Hebisch wrote:
>
> Please consider now trunk frozen for release.

FriCAS 1.3.8 is now released, development is back to normal.
I hope that for next release developement cycle will be
shorter.

--
Waldek Hebisch

[Waldek Hebisch]

On Wed, Jun 22, 2022 at 09:40:53AM +0200, Ralf Hemmecke wrote:
>
> As far as I understand Waldek created the 1.3.8 branch only to have an extra
> commit that sets the version number.

Yes.

> That is similar to the above only that
> 1.3.7 is not a parent of 1.3.8.
>
> I guess the simplest solution now would be to remove the branch names 1.3.7
> and 1.3.8. They are the only "ambiguous" names. For all the other tags there
> is no branch name.

If this "ambiguous" name causes trouble, we could delete it. OTOH
I do not feel good about "rewriting history" in such way...

--
Waldek Hebisch

[Ralf Hemmecke]

> If this "ambiguous" name causes trouble, we could delete it.

I've just deleted the branches 1.3.7 and 1.3.8.
I could not do it via "git push github :1.3.7", because same name for
tag an branch forbid me to do it. I had to go to the github website.

Waldek, maybe next time, you create this temporary branch as "v1.3.9"
(at least something differen from the pure number tag.

> OTOH I do not feel good about "rewriting history" in such way...

I do not think that this is a big problem. Important are the sha1's and
the content in the repository, but branch names are not. If you have
never publicly referred to a branch name, it there is not trace in
history at all.

Actually you could call a temporary branch like "wip/something". I take
the position that Work-in-progress branches can be rebased or even
completely deleted. The "wip/" in the branch name should make everybody
aware that the branch contains something that might suddenly disappear,
so you shouldn´t rely on it. Having such branches is sometimes quite
nice in order to collaborate temporarily on a feature.

Ralf