Tag a release

[DennisOSRM]

Hey, having read #40, I'd like to push again for a tagged release. Reason for asking is that package managers, e.g. Homebrew, won't accept a package for S2 unless there is a tagged version. It would be very much appreciated.

[DennisOSRM]

Friendly ping

[jmr]

https://github.com/google/s2geometry/releases/tag/v0.9.0-2019.02.11.00

[DennisOSRM]

Thanks so much!

[fxcoudert]

This is marked as “pre-release”, is it voluntary?

[jmr]

Yes. We're not guaranteeing API stability yet.

[sgindin]

@jmr is lack of guarantee for the API stability the only thing preventing you from calling this 1.0.0?
And if it is not, is there a roadmap or desire to get there in the future?
IMO API stability alone shouldn't prevent you from cutting a release. For example, I'm pretty sure that for my project the API is stable enough.
@fxcoudert what is the real concern here?

[jmr]

I just wanted to unblock @DennisOSRM while imposing the minimum additional requirements. For release versions, the major number would have to be bumped for changes that aren't backwards compatible.

I think I want to remove the internal copy of abseil-cpp and fix some bugs before releasing a 1.0. Before this issue, we weren't planning on tagging releases at all.

[sgindin]

@jmr I see. Unfortunately Homebrew maintainers are not happy with the 'fake' release. Let me know if I can help with making 1.0.0 happen.

[jmr]

The bug said tag a release, not tag a release >= 1.0.0. What are the homebrew requirements, exactly?

[sgindin]

This is being discussed here Homebrew/homebrew-core#37122
The rules are here https://docs.brew.sh/Acceptable-Formulae
The particular comment from the maintainer:

This is marked as as “pre-release”, which is not suitable for Homebrew core

[jmr]

Will 0.y.z work? Homebrew doesn't say what they think "stable" means. Do they assume everything follows SemVer rules?f

It seems a bit strange to have detailed rules that provide no actual guarantees and ultimately depend on other people doing the right thing, but I guess it works well enough for them in practice.

[fxcoudert]

It seems a bit strange to have detailed rules that provide no actual guarantees and ultimately depend on other people doing the right thing, but I guess it works well enough for them in practice.

Actually, it does :)

We ship 4725 packages, so we have to find rules that are general enough to keep us on the verge of sanity.

• We refuse to ship things that don't follow a versioning system, but we let upstream decide what they consider stable.
• We're okay with 0.x.y releases, because we do know that some usable (and useful) software can take decades to reach a 1.0.0 release, depending on how hard the developers are on themselves.
• We don't ship anything that upstream themselves consider “unstable”, “development”, “alpha” or “beta” releases.

In your case, what worried me was the “pre-release” tag on the github release. We understand that API might change in the future, but what I am wondering is whether you're just tagging this one release to satisfy a user, or if you will be releasing other releases in the not-so-far future.

[jmr]

There will be continued releases.

I'm a bit concerned by the potential for conflicts with other versions of abseil-cpp, which currently doesn't want to be installed, or provide any install functionality (but they have promised it for the future).

[jmr]

@DennisOSRM How urgent is this for you? I could do a 0.9.0 release anytime, but there are always a few more changes I could do first...

[jmr]

@DennisOSRM Can you test https://github.com/google/s2geometry/releases/tag/v0.9.0-2019.03.01.00 ?

If that works for you I'll release v0.9.0.

[sgindin]

@jmr thanks! I'll integrate and test this branch ASAP and let you know.

[sgindin]

@jmr I've encountered an issue trying to build against this version.
https://github.com/google/s2geometry/blame/v0.9.0-2019.03.01.00/src/s2/util/bits/bits.h#L56
This exposes gtest in the public API.

After applying the following patch I could successfully integrate the library and pass all the relevant tests

diff --git a/src/s2/util/bits/bits.h b/src/s2/util/bits/bits.h
index 8053aef..e1cca07 100644
--- a/src/s2/util/bits/bits.h
+++ b/src/s2/util/bits/bits.h
@@ -53,7 +53,7 @@
 
 #include <type_traits>
 
-#include <gtest/gtest_prod.h>
+//#include <gtest/gtest_prod.h>
 
 #include "s2/base/integral_types.h"
 #include "s2/base/logging.h"
@@ -359,8 +359,8 @@ class Bits {
   Bits(Bits const&) = delete;
   void operator=(Bits const&) = delete;
 
-  FRIEND_TEST(Bits, Port32);
-  FRIEND_TEST(Bits, Port64);
+//  FRIEND_TEST(Bits, Port32);
+//  FRIEND_TEST(Bits, Port64);
 };
 
 // A utility class for some handy bit patterns.  The names l and h

[jmr]

@sgindin Good point. Try https://github.com/google/s2geometry/releases/tag/v0.9.0-2019.03.04.00 .

[sgindin]

@jmr, thanks for the quick fix! I confirm that I could successfully build and test my project against v0.9.0-2019.03.04.00.

[jmr]

https://github.com/google/s2geometry/releases/tag/v0.9.0