I think it's fine to have a 24h vote period for "Security" releases, Such releases should be a regular x.y.z version number, no need for a 4th digit. 3rd digit is already bugfixes only. I think a CVE on ous or a dependency that is RCE or information disclosure should be the trigger, and only a bugfix release can get expedited of course. Otherwise normal release. I don't think we should shorten it too far, witness how new information became available regarding further vulnerability.mitigation in this case. Not great to issue releases too quickly as it can lead to releasing something in error with a false sense of security. So if we can shave a couple days of fine, but let's also give some time for proper consideration too.
On Thu, Dec 16, 2021 at 4:01 AM Uwe Schindler <u...@thetaphi.de> wrote: > Hi, > > I agree that we should better take the option to have fast releases. We > should maybe make a rule how many LOC is allowed to shorten the period. > > About the versioning: I would not change the versioning and just add 1 to > the minor release. Plain simple. > > Longer story: If you still want a fourth digit, the versioning schema can > handle this, but the lowest bits (in binary, digits in text form) have some > special meaning (ALPHA, BETA,...) in Lucene's Version.java. So my proposal > for that route would be: As Solr needs its own Version.java anyways > (SolrVersion.java), you can implement it there. But be aware, there's also > Gradle magic and release automation involved. > > For Lucene there's no need for those type of releases, as we are a library > only. > > Uwe > > ----- > Uwe Schindler > Achterdiek 19, D-28357 Bremen > https://www.thetaphi.de > eMail: u...@thetaphi.de > > > -----Original Message----- > > From: Shawn Heisey <apa...@elyograg.org> > > Sent: Thursday, December 16, 2021 2:43 AM > > To: dev@solr.apache.org > > Subject: Should we have an "emergency release" procedure? > > > > The log4j debacle has sure been interesting. > > > > I have heard from at least one user that the project should have reacted > > faster to this problem, in order to get a fixed version available > > quickly. Our release process takes several days even if everything goes > > well, which can be perceived by users as indifference in the face of a > > security concern. > > > > What I am thinking is that we might want to have an emergency release > > process that consists of checking out the tag for the most current > > release available, making as small a change as possible to address a > > vulnerability, and then releasing it quickly, skipping as much of the > > usual delays as possible, like the 72-hour Vote. Maybe reduce that to 4 > > hours or 8 hours. The first number that popped into my fron was 24 > > hours, but that's still a pretty long delay for a major problem like the > > log4j vulnerability. > > > > If the versioning code in Solr can deal with it, what I would think of > > as the version number for a special release in this case would be > > 8.10.0.1 -- to indicate that it is almost completely identical to > > 8.10.0. If the versioning code can't deal with it, I propose that we > > alter it so that it can. > > > > Thoughts from my fellow committers? Is this idea completely bonkers? > > Would there be changes to the idea that might make it better? > > > > Thanks, > > Shawn > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > For additional commands, e-mail: dev-h...@solr.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > For additional commands, e-mail: dev-h...@solr.apache.org > > -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
