Upcoming 0.26.0, please review release notes

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Upcoming 0.26.0, please review release notes

Ivan Vučica-2
cURLable text file available here, in case you wish neither to clone
the repo nor use the GitHub web UI:
  https://raw.githubusercontent.com/gnustep/libs-gui/e2f3923e1361c4f5e38f255557c465abe03b41a9/ANNOUNCE


Now, further remarks:


This release will be created using something called an "annotated tag"
in Git. Annotated tags are not merely references to a commit, but they
are otherwise objects in their own right, and have an author, date and
a commit message of their own.

GitHub (and probably other similar systems) expose them as 'releases'.
Instead of having to attach a message using web UI, the tag commit
message will be used. This means whatever we deploy as a tag commit
message, we can take out when we move from GitHub.

As a less practical, but more of a fun thing, I won't be creating just
an annotated tag but a GPG-signed annotated tag. This means users can
use 'git tag -v gui-0_26_0' to check that the signer claims this
release is genuine. I will be using my personal GPG key for this, as
that will be appropriately displayed in systems that support
displaying that a tag has been correctly signed. If I were to use the
GNUstep Maintainers key, it would not be appropriately displayed as
released by my account. Actual signature *will* be performed with the
correct maintainer GPG key!

You can see all this in action here:
  https://github.com/ivucica/libs-gui/releases/tag/gui-0_26_0

(You may observe that this is not pushed to the mainline repo. That is
because this is *not* yet the 0.26.0 release; I've tagged it only for
preview. Actual tag will be pushed to the main GNUstep repository for
libs-gui. I've manually marked the release as pre-release.)

Preview, prerelease, not-actually-0.26.0 tarball and
personally-signed-.sig (use curl -L to download):
  https://github.com/ivucica/libs-gui/releases/download/gui-0_26_0/gnustep-gui-0.26.0.tar.gz
  https://github.com/ivucica/libs-gui/releases/download/gui-0_26_0/gnustep-gui-0.26.0.tar.gz.sig

To facilitate cutting this release, I have updated gnustep-make. It
now has targets 'git-tag' and 'git-dist' which behave similar to
'svn-tag' and 'svn-dist', except that they operate on local repo only.
They use annotated tags, support keysigning and using a text file as
the source for the tag commit message. All tagging and releasing
operations are on the local repository; pushing tags to a public
repository is left to the developer invoking these convenience
commands.

I've opted to ask for a review of the changes to gnustep-make in case
I use some incompatible feature of GNU Make, or if it's
incomprehensible. If there are no significant comments, I will merge
this shortly.

  https://github.com/gnustep/tools-make/pull/3
or
  https://patch-diff.githubusercontent.com/raw/gnustep/tools-make/pull/3.patch

It should affect only people using gnustep-make to cut releases for
their software.

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 0.26.0, please review release notes

Ivan Vučica-2
On Thu, Dec 7, 2017 at 10:57 PM, Ivan Vučica <[hidden email]> wrote:
> cURLable text file available here, in case you wish neither to clone
> the repo nor use the GitHub web UI:
>   https://raw.githubusercontent.com/gnustep/libs-gui/e2f3923e1361c4f5e38f255557c465abe03b41a9/ANNOUNCE

To add: yes, there is indeed no work on libs-back 0.26.0 done yet.
I'll do that in the next / final round of work, probably Saturday
evening.

And yes, of course the final release will be primarily released
through usual channels such as ftp.gnustep.org.

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 0.26.0, please review release notes

Yavor Doganov-3
In reply to this post by Ivan Vučica-2
В Thu, 07 Dec 2017 22:57:39 +0000, Ivan Vučica написа:

> Actual signature *will* be performed with the correct maintainer GPG
> key!

I don't quite understand this sentence -- does it mean that the actual
tag/release at the official GitHub GNUstep repository will be signed
with the GNUstep maintainer key and you only used your key for the
preview release?  If so, it makes perfect sense.

If I understood everything correctly, the .tar.gz and the accompanied
.sig as generated from the git tag on GitHub will be exactly the same
as those published at ftp.gnustep.org.  How quickly will the files
propagate to ftp.gnustep.org?  Do we (Debian) have to adjust the
(tar.gz/.sig) location to GitHub or we can continue to use
ftp.gnustep.org?

P.S.  I'd suggest to advertise widely this new feature of GNUstep Make
      and recommend that all developers GPG-sign their releases.


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 0.26.0, please review release notes

Ivan Vučica-2
Hey,

Thanks for checking in. Sorry for not being fully clear.

On Fri, Dec 8, 2017, 10:18 Yavor Doganov <[hidden email]> wrote:
В Thu, 07 Dec 2017 22:57:39 +0000, Ivan Vučica написа:

> Actual signature *will* be performed with the correct maintainer GPG
> key!

I don't quite understand this sentence -- does it mean that the actual
tag/release at the official GitHub GNUstep repository will be signed
with the GNUstep maintainer key and you only used your key for the
preview release?  If so, it makes perfect sense.

I will sign the tag with my personal key (otherwise GH would not display it as verified) and I will sign the tarball with the shared maintainer key, as is the usual practice.

If I understood everything correctly, the .tar.gz and the accompanied
.sig as generated from the git tag on GitHub will be exactly the same
as those published at ftp.gnustep.org.  How quickly will the files
propagate to ftp.gnustep.org?  Do we (Debian) have to adjust the
(tar.gz/.sig) location to GitHub or we can continue to use
ftp.gnustep.org?

Please use ftp.gnustep.org as the primary distribution point.

Anything published on Github is merely a convenience. Long-term plan is still to move away from Github as the main repo due to concerns in the community. No time estimates on that, however.

The change is simply in the build process, and an additional secondary distribution point.


P.S.  I'd suggest to advertise widely this new feature of GNUstep Make
      and recommend that all developers GPG-sign their releases.

My understanding is that was already the practice for GNUstep core project? :-)

What I mean is: we are already supposed to sign the tarballs.

The only new thing is signing tags, which I'm doing more for fun than anything else: we have not discussed moving to git repository as the primary source of releases (nor would I really see many advantages to moving away from GNU practices in such a way). :-)

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 0.26.0, please review release notes

Yavor Doganov-3
В Fri, 08 Dec 2017 10:55:14 +0000, Ivan Vučica написа:
> On Fri, Dec 8, 2017, 10:18 Yavor Doganov <[hidden email]> wrote:

> I will sign the tag with my personal key (otherwise GH would not display
> it as verified) and I will sign the tarball with the shared maintainer
> key, as is the usual practice.

OK, I thought that GitHub automatically generates tarballs from git
tags, at least this is what I observed with SimpleAgenda.  So it is
slightly consufing for me how the tag can be signed with one signature
and the tarball with another.  Anyway, these details are not so
important for me, as long as the tarball is signed with the proper key.

> Please use ftp.gnustep.org as the primary distribution point.

OK, thanks.

>> P.S.  I'd suggest to advertise widely this new feature of GNUstep Make
>>       and recommend that all developers GPG-sign their releases.
>>
> My understanding is that was already the practice for GNUstep core
> project?
> :-)
>
> What I mean is: we are already supposed to sign the tarballs.

GNUstep core packages have always been signed, I think.  But there are
lots of unsigned tarballs at ftp.gnustep.org and the other non-core
distribution locations (GAP, gnustep-nonfsf, gsimages, etc.).  Some
maintainers sign a particular release and then don't sign the next
which is a problem for Debian packaging, because once you setup the
package to verify upstream's signature, a subsequent release that is
not GPG-signed will be rejected by the archive management software.

> The only new thing is signing tags, which I'm doing more for fun than
> anything else:

Well, signing tags is a good practice from security POV.  Some people
even insist that each commit should be GPG-signed.


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 0.26.0, please review release notes

Fred Kiefer
In reply to this post by Ivan Vučica-2
Hi Ivan,

all of this looks great to me. One thing I did not understand is why the Announce file in the tag is less complete, then on the master branch. But this surely will be corrected for the real release.
I still would like to see a coordinated release of base, gui and back. With make I am a bit unsure. Your latest change there seems to be the only commit for this module. So it is up to decide whether a release is needed.

Thank you for working on this,
Fred

> Am 07.12.2017 um 23:57 schrieb Ivan Vučica <[hidden email]>:
>
> cURLable text file available here, in case you wish neither to clone
> the repo nor use the GitHub web UI:
>  https://raw.githubusercontent.com/gnustep/libs-gui/e2f3923e1361c4f5e38f255557c465abe03b41a9/ANNOUNCE
>
>
> Now, further remarks:
>
>
> This release will be created using something called an "annotated tag"
> in Git. Annotated tags are not merely references to a commit, but they
> are otherwise objects in their own right, and have an author, date and
> a commit message of their own.
>
> GitHub (and probably other similar systems) expose them as 'releases'.
> Instead of having to attach a message using web UI, the tag commit
> message will be used. This means whatever we deploy as a tag commit
> message, we can take out when we move from GitHub.
>
> As a less practical, but more of a fun thing, I won't be creating just
> an annotated tag but a GPG-signed annotated tag. This means users can
> use 'git tag -v gui-0_26_0' to check that the signer claims this
> release is genuine. I will be using my personal GPG key for this, as
> that will be appropriately displayed in systems that support
> displaying that a tag has been correctly signed. If I were to use the
> GNUstep Maintainers key, it would not be appropriately displayed as
> released by my account. Actual signature *will* be performed with the
> correct maintainer GPG key!
>
> You can see all this in action here:
>  https://github.com/ivucica/libs-gui/releases/tag/gui-0_26_0
>
> (You may observe that this is not pushed to the mainline repo. That is
> because this is *not* yet the 0.26.0 release; I've tagged it only for
> preview. Actual tag will be pushed to the main GNUstep repository for
> libs-gui. I've manually marked the release as pre-release.)
>
> Preview, prerelease, not-actually-0.26.0 tarball and
> personally-signed-.sig (use curl -L to download):
>  https://github.com/ivucica/libs-gui/releases/download/gui-0_26_0/gnustep-gui-0.26.0.tar.gz
>  https://github.com/ivucica/libs-gui/releases/download/gui-0_26_0/gnustep-gui-0.26.0.tar.gz.sig
>
> To facilitate cutting this release, I have updated gnustep-make. It
> now has targets 'git-tag' and 'git-dist' which behave similar to
> 'svn-tag' and 'svn-dist', except that they operate on local repo only.
> They use annotated tags, support keysigning and using a text file as
> the source for the tag commit message. All tagging and releasing
> operations are on the local repository; pushing tags to a public
> repository is left to the developer invoking these convenience
> commands.
>
> I've opted to ask for a review of the changes to gnustep-make in case
> I use some incompatible feature of GNU Make, or if it's
> incomprehensible. If there are no significant comments, I will merge
> this shortly.
>
>  https://github.com/gnustep/tools-make/pull/3
> or
>  https://patch-diff.githubusercontent.com/raw/gnustep/tools-make/pull/3.patch
>
> It should affect only people using gnustep-make to cut releases for
> their software.
>
> _______________________________________________
> Gnustep-dev mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/gnustep-dev


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 0.26.0, please review release notes

Ivan Vučica-2
This is a very good point.

I did not spot that the annotated tag’s object did not contain the correct ANNOUNCE. It certainly was supposed to be sourcing the file as it is on the disk, and I am not sure how it used the older revision of the file to tag the newer commit. Maybe Make did not rebuild the temp file. If this is correct, I’ll address it in -make.

I don’t think -make *needs* a release; the change I made is only useful to people who want to cut releases using Git. It’s not super important for other dependencies.

I have no opinion on whether we need a synced release; -gui is certainly in need of it as Debian is blocked from pulling in even 0.25.1.
sub, 9. pro 2017. u 13:28 Fred Kiefer <[hidden email]> napisao je:
Hi Ivan,

all of this looks great to me. One thing I did not understand is why the Announce file in the tag is less complete, then on the master branch. But this surely will be corrected for the real release.
I still would like to see a coordinated release of base, gui and back. With make I am a bit unsure. Your latest change there seems to be the only commit for this module. So it is up to decide whether a release is needed.

Thank you for working on this,
Fred

> Am 07.12.2017 um 23:57 schrieb Ivan Vučica <[hidden email]>:
>
> cURLable text file available here, in case you wish neither to clone
> the repo nor use the GitHub web UI:
https://raw.githubusercontent.com/gnustep/libs-gui/e2f3923e1361c4f5e38f255557c465abe03b41a9/ANNOUNCE
>
>
> Now, further remarks:
>
>
> This release will be created using something called an "annotated tag"
> in Git. Annotated tags are not merely references to a commit, but they
> are otherwise objects in their own right, and have an author, date and
> a commit message of their own.
>
> GitHub (and probably other similar systems) expose them as 'releases'.
> Instead of having to attach a message using web UI, the tag commit
> message will be used. This means whatever we deploy as a tag commit
> message, we can take out when we move from GitHub.
>
> As a less practical, but more of a fun thing, I won't be creating just
> an annotated tag but a GPG-signed annotated tag. This means users can
> use 'git tag -v gui-0_26_0' to check that the signer claims this
> release is genuine. I will be using my personal GPG key for this, as
> that will be appropriately displayed in systems that support
> displaying that a tag has been correctly signed. If I were to use the
> GNUstep Maintainers key, it would not be appropriately displayed as
> released by my account. Actual signature *will* be performed with the
> correct maintainer GPG key!
>
> You can see all this in action here:
https://github.com/ivucica/libs-gui/releases/tag/gui-0_26_0
>
> (You may observe that this is not pushed to the mainline repo. That is
> because this is *not* yet the 0.26.0 release; I've tagged it only for
> preview. Actual tag will be pushed to the main GNUstep repository for
> libs-gui. I've manually marked the release as pre-release.)
>
> Preview, prerelease, not-actually-0.26.0 tarball and
> personally-signed-.sig (use curl -L to download):
https://github.com/ivucica/libs-gui/releases/download/gui-0_26_0/gnustep-gui-0.26.0.tar.gz
https://github.com/ivucica/libs-gui/releases/download/gui-0_26_0/gnustep-gui-0.26.0.tar.gz.sig
>
> To facilitate cutting this release, I have updated gnustep-make. It
> now has targets 'git-tag' and 'git-dist' which behave similar to
> 'svn-tag' and 'svn-dist', except that they operate on local repo only.
> They use annotated tags, support keysigning and using a text file as
> the source for the tag commit message. All tagging and releasing
> operations are on the local repository; pushing tags to a public
> repository is left to the developer invoking these convenience
> commands.
>
> I've opted to ask for a review of the changes to gnustep-make in case
> I use some incompatible feature of GNU Make, or if it's
> incomprehensible. If there are no significant comments, I will merge
> this shortly.
>
https://github.com/gnustep/tools-make/pull/3
> or
https://patch-diff.githubusercontent.com/raw/gnustep/tools-make/pull/3.patch
>
> It should affect only people using gnustep-make to cut releases for
> their software.
>
> _______________________________________________
> Gnustep-dev mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/gnustep-dev


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 0.26.0, please review release notes

Fred Kiefer


> Am 09.12.2017 um 14:43 schrieb Ivan Vučica <[hidden email]>:
>
> I have no opinion on whether we need a synced release; -gui is certainly in need of it as Debian is blocked from pulling in even 0.25.1.

Turns out some to the changes Daniel made in gui require the new enums he added to base. That is, GNUstep gui 0.26.0 depends on the unreleased GNustep base. That way Debian and all the other systems won’t benefit from that gui release until there is also a base release. And we need to update the documented required base version in gui.

Fred


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 0.26.0, please review release notes

Ivan Vučica-2

I'm happy to help as needed.


On Sun, Dec 10, 2017, 20:26 Fred Kiefer <[hidden email]> wrote:


> Am 09.12.2017 um 14:43 schrieb Ivan Vučica <[hidden email]>:
>
> I have no opinion on whether we need a synced release; -gui is certainly in need of it as Debian is blocked from pulling in even 0.25.1.

Turns out some to the changes Daniel made in gui require the new enums he added to base. That is, GNUstep gui 0.26.0 depends on the unreleased GNustep base. That way Debian and all the other systems won’t benefit from that gui release until there is also a base release. And we need to update the documented required base version in gui.

Fred


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 0.26.0, please review release notes

Fred Kiefer
I was hoping for Richard to step up here. If he doesn’t response today, we should try to go ahead ourselves. I could help later today with the news.texi file. My impression is that we should use a version number of 1.26.0 as quite a few changes have piled up.
The release process itself would again be on your side, as you have the required key for it. It would be great to have this one out tonight to reduce the confusion that comes from the gui release.
Not sure whether we need another gui release to document the increased base version. I think we could do without it.

Fred

> Am 11.12.2017 um 00:03 schrieb Ivan Vučica <[hidden email]>:
>
> I'm happy to help as needed.
>
>
> On Sun, Dec 10, 2017, 20:26 Fred Kiefer <[hidden email]> wrote:
>
>
> > Am 09.12.2017 um 14:43 schrieb Ivan Vučica <[hidden email]>:
> >
> > I have no opinion on whether we need a synced release; -gui is certainly in need of it as Debian is blocked from pulling in even 0.25.1.
>
> Turns out some to the changes Daniel made in gui require the new enums he added to base. That is, GNUstep gui 0.26.0 depends on the unreleased GNustep base. That way Debian and all the other systems won’t benefit from that gui release until there is also a base release. And we need to update the documented required base version in gui.
>
> Fred


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 0.26.0, please review release notes

David Chisnall
Is it possible to just push out a minor release to base that adds the missing enum?  I am working on some fixes for memory management in base that I’d like to make it into the next release, but I can’t guarantee finishing in the next couple of days.

David

> On 11 Dec 2017, at 07:45, Fred Kiefer <[hidden email]> wrote:
>
> I was hoping for Richard to step up here. If he doesn’t response today, we should try to go ahead ourselves. I could help later today with the news.texi file. My impression is that we should use a version number of 1.26.0 as quite a few changes have piled up.
> The release process itself would again be on your side, as you have the required key for it. It would be great to have this one out tonight to reduce the confusion that comes from the gui release.
> Not sure whether we need another gui release to document the increased base version. I think we could do without it.
>
> Fred
>
>> Am 11.12.2017 um 00:03 schrieb Ivan Vučica <[hidden email]>:
>>
>> I'm happy to help as needed.
>>
>>
>> On Sun, Dec 10, 2017, 20:26 Fred Kiefer <[hidden email]> wrote:
>>
>>
>>> Am 09.12.2017 um 14:43 schrieb Ivan Vučica <[hidden email]>:
>>>
>>> I have no opinion on whether we need a synced release; -gui is certainly in need of it as Debian is blocked from pulling in even 0.25.1.
>>
>> Turns out some to the changes Daniel made in gui require the new enums he added to base. That is, GNUstep gui 0.26.0 depends on the unreleased GNustep base. That way Debian and all the other systems won’t benefit from that gui release until there is also a base release. And we need to update the documented required base version in gui.
>>
>> Fred
>
>
> _______________________________________________
> Gnustep-dev mailing list
> [hidden email]
> https://lists.gnu.org/mailman/listinfo/gnustep-dev


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 0.26.0, please review release notes

Richard Frith-Macdonald-9
In reply to this post by Fred Kiefer


> On 11 Dec 2017, at 07:45, Fred Kiefer <[hidden email]> wrote:
>
> I was hoping for Richard to step up here. If he doesn’t response today, we should try to go ahead ourselves. I could help later today with the news.texi file. My impression is that we should use a version number of 1.26.0 as quite a few changes have piled up.
> The release process itself would again be on your side, as you have the required key for it. It would be great to have this one out tonight to reduce the confusion that comes from the gui release.
> Not sure whether we need another gui release to document the increased base version. I think we could do without it.

I was away, and just got home last night.
I had intended to make a release befoire christmas.  As far as I know there should be nothng that breaks binary compatibility (so I'd have made it 1.25.1), but if people want a new library version number I don't see any problem with that.



_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 0.26.0, please review release notes

Ivan Vučica-2
@rfm: Happy to assist with the new release process if you have any
issues. While you've seen the pull request that I just merged, for
other people's reference I'd suggest:
- make git-tag, while passing the GIT_TAG_ANNOUNCE_FILE=put-announce-file-here
- if you have your GPG key around, also pass GIT_TAG_SIGN=yes or
GIT_TAG_SIGN=key_id_here
- make git-dist
- sign the tarball with maintainer key as you've previously helped me do
- I'd git push --tags once you're sure all works well.

I have no opinion about bumping the -base version.

I am happy to cut a minor release 0.26.1 to make new -base version required.

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 0.26.0, please review release notes

Ivan Vučica-2
In reply to this post by David Chisnall
On Mon, Dec 11, 2017 at 9:33 AM, David Chisnall <[hidden email]> wrote:
> Is it possible to just push out a minor release to base that adds the missing enum?  I am working on some fixes for memory management in base that I’d like to make it into the next release, but I can’t guarantee finishing in the next couple of days.

I think it's also fine to push a new minor release *after* this
release with just your changes. Does that make sense too?

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 0.26.0, please review release notes

David Chisnall
On 11 Dec 2017, at 10:33, Ivan Vučica <[hidden email]> wrote:
>
> On Mon, Dec 11, 2017 at 9:33 AM, David Chisnall <[hidden email]> wrote:
>> Is it possible to just push out a minor release to base that adds the missing enum?  I am working on some fixes for memory management in base that I’d like to make it into the next release, but I can’t guarantee finishing in the next couple of days.
>
> I think it's also fine to push a new minor release *after* this
> release with just your changes. Does that make sense too?

It’s likely to change some of the -base / libobjc2 interfaces and possibly be a requirement of the new libobjc2, so I’d prefer a major version bump then, but it probably doesn’t have to be one.

I’ve committed the fixes for NSMapTable where we were using the wrong hash and equality functions if you use the normal constructors - those are probably the most important things to get out.

David


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 0.26.0, please review release notes

Ivan Vučica-2
On Mon, Dec 11, 2017 at 10:43 AM, David Chisnall <[hidden email]> wrote:
> On 11 Dec 2017, at 10:33, Ivan Vučica <[hidden email]> wrote:
>> I think it's also fine to push a new minor release *after* this
>> release with just your changes. Does that make sense too?
>
> It’s likely to change some of the -base / libobjc2 interfaces and possibly be a requirement of the new libobjc2, so I’d prefer a major version bump then, but it probably doesn’t have to be one.
>
> I’ve committed the fixes for NSMapTable where we were using the wrong hash and equality functions if you use the normal constructors - those are probably the most important things to get out.

Makes sense.

I think that we can still do a major version bump in a few days, even
if it includes "just" your new fixes.

I've just spent some time cutting -gui and -back so it would be a
minor effort for me if I were to do it.

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 0.26.0, please review release notes

David Chisnall
On 11 Dec 2017, at 10:46, Ivan Vučica <[hidden email]> wrote:

>
> On Mon, Dec 11, 2017 at 10:43 AM, David Chisnall <[hidden email]> wrote:
>> On 11 Dec 2017, at 10:33, Ivan Vučica <[hidden email]> wrote:
>>> I think it's also fine to push a new minor release *after* this
>>> release with just your changes. Does that make sense too?
>>
>> It’s likely to change some of the -base / libobjc2 interfaces and possibly be a requirement of the new libobjc2, so I’d prefer a major version bump then, but it probably doesn’t have to be one.
>>
>> I’ve committed the fixes for NSMapTable where we were using the wrong hash and equality functions if you use the normal constructors - those are probably the most important things to get out.
>
> Makes sense.
>
> I think that we can still do a major version bump in a few days, even
> if it includes "just" your new fixes.
>
> I've just spent some time cutting -gui and -back so it would be a
> minor effort for me if I were to do it.


I had some time to finish up most of the changes and have sent a pull request for review.  I think I probably want to add a couple of weak functions for refcount manipulation that will allow either the runtime or -base to provide them, depending on the versions of each.

David


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 0.26.0, please review release notes

Ivan Vučica-2
On Mon, Dec 11, 2017 at 4:45 PM, David Chisnall <[hidden email]> wrote:
> I had some time to finish up most of the changes and have sent a pull request for review.  I think I probably want to add a couple of weak functions for refcount manipulation that will allow either the runtime or -base to provide them, depending on the versions of each.

Ok.

I thought about the next step and I think I'll actually just wait for
Richard to review your PR, and to cut a new release (or tell me to do
it). That way we know what to bump -gui's opinion of required -base
version to.

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 0.26.0, please review release notes

Yavor Doganov-3
In reply to this post by Richard Frith-Macdonald-9
В Mon, 11 Dec 2017 09:45:04 +0000, Richard Frith-Macdonald написа:

> As far as I know there should be nothng that breaks binary
> compatibility (so I'd have made it 1.25.1), but if people want a new
> library version number I don't see any problem with that.

Please don't bump the SONAME if the changes don't break binary
compatibility.  Superfluous bumping is not so bad as retaining the
SONAME if there's ABI breakage but it's not a good practice and leads
to unnecessary burden for users and distros.


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Upcoming 0.26.0, please review release notes

David Chisnall
On 11 Dec 2017, at 21:04, Yavor Doganov <[hidden email]> wrote:

>
> В Mon, 11 Dec 2017 09:45:04 +0000, Richard Frith-Macdonald написа:
>
>> As far as I know there should be nothng that breaks binary
>> compatibility (so I'd have made it 1.25.1), but if people want a new
>> library version number I don't see any problem with that.
>
> Please don't bump the SONAME if the changes don't break binary
> compatibility.  Superfluous bumping is not so bad as retaining the
> SONAME if there's ABI breakage but it's not a good practice and leads
> to unnecessary burden for users and distros.

While I agree that it’s bad form, at least for FreeBSD it doesn’t make any difference for the packagers.  We will rebuild all of the packages that depend on -base when there are any changes to the -base library, whether the SO version has changed or not.  

It takes less than 24 hours to build the entire 30,000 package set on a single machine these days and it’s far better to burn some cycles unnecessarily than to ship a package set with ABI breakage.  Even if the ABI is backwards compatible, there may be changes to the headers that will cause dependent software to enable new features at compile time, so skipping a rebuild is usually a bad idea.

David


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
12