I would suggest that we wait for the new Artifact Distribution Platform and plan for cTAKES 5.0 as churning out a new release in the traditional way may get disconnected once the new distribution platform is out.
+1 on waiting. On Wed, 8 Mar 2023 at 18:59, Finan, Sean <sean.fi...@childrens.harvard.edu.invalid> wrote: > Hi all Apache cTAKES developers and users, > > I have news on the release front ... > > The Apache Infrastructure team is working on a new Artifact Distribution > Platform. It will be used to upload and promote release artifacts, sign > keys, and host distributions in a fashion that is informative and > attractive to a user. > > Some of the old/current items that are part of an Apache project release > are going to be "legacy" and there are some new metadata items that go with > a release artifact. > > I see two paths moving forward: > > > 1. We push on with a release of cTAKES 5.0 and release in the current > style. > 2. We wait a couple of months until the Apache Infrastructure team has > the new Artifact Distribution Platform ready and use it to release. > > For #1 please keep in mind that we still haven't had a volunteer for the > primary Release Manager. Gandhi Rajan has volunteered to be co-RM but it > will be a two-person job. > > Either way can create Release Candidate source branches on GitHub to be > tested and have issues posted on the cTAKES GitHub issues list. > > This manner of Release Candidate testing would be a deviation from the > method of creating Release Candidate artifacts including binary > installations and putting them in a Subversion (svn) repository online. > We can probably place "binary installation" artifacts on GitHub, but > somebody will need to check on space limits and other rules before we can > make any promises there. If there is some barrier there then testers would > need to test binary installations by build/packaging locally on their > system - which is a good thing to have tested anyway. > > So, please post any thoughts or questions in reply to this email and we > can try to figure out where to go from here. > > Many thanks, > > Sean > > ________________________________ > From: Finan, Sean <sean.fi...@childrens.harvard.edu.INVALID> > Sent: Monday, February 20, 2023 5:12 PM > To: dev@ctakes.apache.org <dev@ctakes.apache.org>; u...@ctakes.apache.org > <u...@ctakes.apache.org> > Subject: It is Official! Steps toward a cTAKES 5.0 release. [EXTERNAL] > [SUSPICIOUS] > > * External Email - Caution * > > > Hi all, > > The cTAKES Project Management Committee has voted that it is time to > officially begin the release process for cTAKES 5.0 > > It has been almost 6 years since version 4.0.0 was released, and with a > worldwide user count estimated in the thousands, a new release will be > extremely valuable. > > Releasing cTAKES 5.0 will involve some work, and the project needs > volunteers to assist in the process. > > The most important thing right now is the appointment of a Release Manager > (RM). > While the position is not to be taken lightly and does involve work, it > can be a great experience (and a resume builder). > > We need a cTAKES committer to be the RM, but I am going to split the > general responsibilities below. > I am doing this because I believe that any user familiar with cTAKES can > be a co-RM. > > Requiring a committer: > 1. Creating Release Candidates of the code. > 2. Deploying and Signing the actual Official Release. > > Not requiring a committer: > 1. Coordinating people performing documentation, testing and bug fixing. > 2. Communicating progress with the developer list. > > I am sure that I am forgetting something, but those are the 4 tasks that I > can think of right now. > > If you would like to be the Release Manager (or a co-RM), please volunteer > on the dev@ctakes.apache.org mailing list. > > Other tasks that must be performed for a release include: > 1. Testing the release candidates. > 3. Contributing documentation. > 2. Writing fixes for bugs that can be fixed for the release. > 4. Updating the release information on ctakes.apache.org > > Anybody can test release candidates. There are countless pipelines that > can be built and tested, but I think that we should try to cover the 'most > commonly used' pipelines. If you run any pipeline, please report success - > even if you don't run it specifically for release testing. > Documentation can be contributed by any user. A cTAKES committer is > required to actually push the documentation to the wiki, readme, release > notes, etc. Sending out markdown, images, plain text or just > recommendations is open to all users. > While only committers can actually push changes to cTAKES code, any user > can contribute fixes by creating code patches or even just copy-pasting > code in an email. > Updating the ctakes.apache.org website will require a committer, but > non-committer assistance is possible just like it is for bug fixes. > > One person (Tim Miller) has already volunteered to perform testing and > another (Dennis Johns) is currently working on the GitHub wiki. > I don't think that people need to officially volunteer to perform last 4 > listed tasks, but it may be beneficial to identify areas that you would > like to cover in order to prevent duplicated work. > > I suspect that I am forgetting at least some minor items, but they will > come to light when encountered. > > I urge you all to take part in the release process. You can earn good > karma, become famous as a cTAKES power user, and perhaps be nominated as a > Committer! > > Thank you all, > > Sean > > -- Regards, Gandhi "The best way to find urself is to lose urself in the service of others !!!"