Re: Podling Baremaps Report Reminder - March 2023

Hello Everyone, Would someone (maybe Andrea or James) be interested to write the next report? I think it is a good idea if we start rotating this task. Since the last report, we released a new version of the web site and we may still be able to drop a first incubating release with a DISCLAIMER-

Re: Podling Baremaps Report Reminder - March 2023

We still need to have mentors vote on the release even if we have the WIP disclaimer. On Fri, Mar 3, 2023 at 6:50 AM Bertil Chapuis wrote: > Hello Everyone, > > Would someone (maybe Andrea or James) be interested to write the next > report? I think it is a good idea if we start rotating this tas

Re: Setting up Intellij Docs

I think the idea was mainly to document the way we use the .run files: https://github.com/apache/incubator-baremaps/tree/main/.run Also, it may be useful to configure IntelliJ so that it uses the eclipse code style, but personally I a

Re: Podling Baremaps Report Reminder - March 2023

Ok, so the process would be to make a release candidate and then to ask the mentors to vote on the mailing-list. Is that right? Can the release candidate be in a branch, so that we can remove it once the vote passes and the final release is published? > On 3 Mar 2023, at 13:54, Josh Fischer

Re: Podling Baremaps Report Reminder - March 2023

In the past with Heron, I created release candidates as tags off of main and marked them as a pre-release. The tag name would be something like: heron-0.20.5-incubating-rc1 Then we would do a vote etc. Once the vote passed or failed the tags remained In the repo. Not saying it must be done thi

Re: Podling Baremaps Report Reminder - March 2023

Our release process currently relies on the maven release plugin. It changes the version number in all our pom.xml files, commit the changes, and creates a tag for the release. If this tag starts with the letter “v” a release workflow will be started by GitHub actions [1]. We could create a ta

Re: Podling Baremaps Report Reminder - March 2023

I think an issue may arise with removing commits associated with RC's. When we start a vote, we list the commit hash of the source package to be voted upon. If you remove those commits, I believe it would invalidate the work put into the voting process, as that commit doesn't exist anymore and the

Re: Podling Baremaps Report Reminder - March 2023

If you give each RC a tag, and push that tag, then you are not removing the commit. The commit is still reachable via the tag. One possible process is as follows. You could pause commits to main during the release process. Make the release candidates on a branch that is one commit ahead of main