Kenn, Thank you for your thoughtful comments! 1. The versioning / branching / tagging / SNAPSHOT / RC / Release process.
We actually had a long discussion on this and discussed several variations. We were hoping to keep it simple and not have a separate branch for each release, but you bring up a good point about always having master with SNAPSHOT, so it can never be accidentally forked and confused with a real release. We will move to this for the next go around. 2. Putting Jars in Maven Central prior to the Vote. Since we are talking about RCs, it wasn't clear to me that ASF would approve of a podling putting RCs into staging before the vote. If it is OK, we will definitely do that the next go around. ## A question for you: Is it possible to deploy RCs (or Releases) directly to Maven Central using the command line or SVN (or SFTP) ? (i.e., without using Maven). 3. Adding slf4j backend. Good suggestion. We will fix that on the next go around. 4. Are our Javadocs versioned? Effectively yes (but the user has to do a wee bit of work :) ) - From the dist Zip file: after the user unzips the package they can generate their own Javadocs easily. - When we release to Maven Central we deploy a javadoc.jar along with the other release jars. However, so far we have wanted the Javadocs visible from the website to be the latest and greatest, thus are snapshots. We could easily change this to showing only the latest release Javadocs, but have not made this explicit decision. 5. The voting rules: You might say only IPMC members' votes are binding. This is true only for the vote on general@incubator. For the podling, the PPMC votes should be considered binding as to whether or not the artifact should go on to the IPMC vote. "whether or not the artifact should go on to the IPMC vote" is still fuzzy because Mentors are IPMC members. Are you saying the following? a) On dev@: The VOTE letter is issued and voting stays open for 72+ hours. The PPMC members (not mentors who are IPMC members) vote. When a majority or 3 (+1) votes are collected the baton is handed to the Mentors to vote. When a majority or 3 (+1) votes are collected from the Mentors the baton is handed to incubator@general b) On incubator@general The VOTE letter is issued and voting stays open for 72+ hours. When a majority or 3 (+1) binding votes (other IPMC members) are collected, *then* we can deploy a Release. BTW, I have not seen this level of process detail described anywhere. I am not objecting, it is just that more clarity would have been helpful :) Lee. On Wed, Jul 24, 2019 at 3:20 PM Kenneth Knowles <[email protected]> wrote: > On Tue, Jul 23, 2019 at 3:37 PM leerho <[email protected]> wrote: > > > > > NOTE 2: All of the code has been properly refactored with > > "org.apache.datasketches...". > > All source files have the proper Apache license and have been checked > with > > the Maven Rat Plugin. > > The code passes all tests with a coverage of > 98%. > > > > This is really great to have done. Nice! > > > > Git Tag for this release: > > > > > https://github.com/apache/incubator-datasketches-memory/tree/1.0.0-incubating-RC2 > > > > I notice that throughout the git history every commit has version > 1.0.0-incubating. You may have considered this already, but maven supports > 1.0.0-incubating-SNAPSHOT which will avoid inappropriate caching. At > publish time it will be replaced with a timestamp, if I recall the exact > system. So it often makes sense for every mainline commit on the master > branch to have this version in the pom.xml and you just make a single > tagged commit not on master where the version has been changed. > > master --a--b--c--d--e--f-- ... > \ \ > x y > > All of a, b, c, d, e, f can have a SNAPSHOT version while x and y, which > exist just to build an RC, can have a non-SNAPSHOT version. > > 5. Repository: Maven Central (repository.apache.org): > > > > Upon acceptance the jar artifacts will be generated from the source > > repository and deployed > > to the Apache Maven Central staging repository: > > > > > > > https://repository.apache.org/content/groups/staging/org/apache/datasketches/memory/ > > > > It might be nice to do the staging prior to the vote. Technically they are > "convenience binaries" but it is helpful to test them as well, to uncover > any problems before approving the release. Avoids voting +1 on source that > ends up building a bad binary. > > > > $ mvn clean test -P strict > > > > Note also that when running the test suite, you might get the following > > message: > > > > SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". > > SLF4J: Defaulting to no-operation (NOP) logger implementation > > SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for > > further details. > > > > This is normal. It just indicates that in your environment, you do not > > have a logger in your class-path so the default logger of a no-op is used > > instead. > > > > You should be able to add an slf4j backend to the <scope>test</scope> in > your pom.xml so it does not depend on the user/contributor to do so. > > The documentation for the DataSketches Memory component is part of the > > website. > > > > Overview documentation: > > - https://datasketches.github.io/docs/Memory/MemoryPackage.html > > - https://datasketches.github.io/docs/Memory/MemoryPerformance.html > > > > Javadocs: > > https://datasketches.github.io/api/memory/snapshot/apidocs/index.html > > > > Is there a versioned revision to the javadocs that could also be previewed > as part of the RC? > > 8. The vote will be performed in two stages: > > - This letter will be published on dev@ open for at least 72 hours or > > until necessary number of votes are reached. > > - This letter will be published on incubator@general for at least 72 > > hours or until necessary number of votes are reached. > > > > As mentioned on the [VOTE] thread, votes should stay open for 72 hours. > > > > > Anybody can vote, but only IPMC member's votes count. > > > > You might say only IPMC members' votes are binding. This is true only for > the vote on general@incubator. For the podling, the PPMC votes should be > considered binding as to whether or not the artifact should go on to the > IPMC vote. > > > > The Apache DataSketches Team > > > > I believe you should sign your emails as yourself. > > Kenn >
