You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tooling.apache.org by "sbp (via GitHub)" <gi...@apache.org> on 2025/12/03 15:54:00 UTC
[I] Clarify and constrain permitted ASF TLP version numbers (tooling-trusted-releases)
sbp opened a new issue, #388:
URL: https://github.com/apache/tooling-trusted-releases/issues/388
From a comment I made on #386:
> Many of our TLPs have current `M[0-9]+` and `rc[0-9]+` releases. Perhaps we should document and model this situation as encompassing internal (ATR revision or tag) pre-releases and external (`M[0-9]+`, `rc[0-9]+` etc. in the finished release) pre-releases? But [our release policy](https://www.apache.org/legal/release-policy.html) clearly says:
>
> > **Projects MUST direct outsiders towards official releases rather than raw source repositories, nightly builds, snapshots, release candidates, or any other similar packages.** [...] **Do not include any links on the project website that might encourage non-developers to download and use nightly builds, snapshots, release candidates, or any other similar package.**
>
> In bold per the original. This may imply that TLPs have some kind of need that is not covered by the release policy, or that they are unaware of this part of the policy, or that I am misreading the situation. The policy also says:
>
> > **Release Candidates** are packages that have been proposed for approval as a release but have not yet been approved by the project.
>
> Only approved packages can have a final release on ATR, so we should probably look for rc, alpha, beta, and milestone tags in submitted revision numbers and disallow or strongly warn the release manager. We allow such tags in filenames because they can be stripped out in the final phase before announcement, as a special case. This is a bit complicated but we thought it was a good compromise.
We should clarify which of the _de facto_ or _de jure_ situations needs to be reflected in ATR. Unless we hear to the contrary we will go with the _de jure_ situation and follow the ASF release policy in forbidding version numbers which appear to contain a pre-release component.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Clarify and constrain permitted ASF TLP version numbers (tooling-trusted-releases)
Posted by "sbp (via GitHub)" <gi...@apache.org>.
sbp commented on issue #388:
URL: https://github.com/apache/tooling-trusted-releases/issues/388#issuecomment-3607583378
Note that Airflow have an interesting approach to this: as I understand it, they build RC and non-RC tagged versions simultaneously, distribute the RC tagged versions to their participants for voting, but consider the vote to be held on the non-RC tagged versions which are then released. If there were a [diffoscope](https://diffoscope.org/) style proof of minimal (tag only) differences between the artifacts, we could include this in the attestations that ATR makes. This should be reflected in the official ASF release policy, because at present this practice, if I understood it, is outside of that policy.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Clarify and constrain permitted ASF TLP version numbers (tooling-trusted-releases)
Posted by "dave2wave (via GitHub)" <gi...@apache.org>.
dave2wave commented on issue #388:
URL: https://github.com/apache/tooling-trusted-releases/issues/388#issuecomment-4007756372
We should meet something close to either [semver](https://semver.org) or [calver](https://calver.org), but we should make sure that historical versioning can pass as well.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Clarify and constrain permitted ASF TLP version numbers (tooling-trusted-releases)
Posted by "dave2wave (via GitHub)" <gi...@apache.org>.
dave2wave closed issue #388: Clarify and constrain permitted ASF TLP version numbers
URL: https://github.com/apache/tooling-trusted-releases/issues/388
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Clarify and constrain permitted ASF TLP version numbers (tooling-trusted-releases)
Posted by "dave2wave (via GitHub)" <gi...@apache.org>.
dave2wave commented on issue #388:
URL: https://github.com/apache/tooling-trusted-releases/issues/388#issuecomment-3702794090
There are situations where projects do release with tags like:
1. `-RC[0-9]*`
2. `-ALPHA[0-9]*`
3. `-BETA[0-9]*`
4. `-M[0-9]*`
Not inclusive, but we need to allow these,
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Clarify and constrain permitted ASF TLP version numbers (tooling-trusted-releases)
Posted by "dave2wave (via GitHub)" <gi...@apache.org>.
dave2wave commented on issue #388:
URL: https://github.com/apache/tooling-trusted-releases/issues/388#issuecomment-3608389040
See #389
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Clarify and constrain permitted ASF TLP version numbers (tooling-trusted-releases)
Posted by "dave2wave (via GitHub)" <gi...@apache.org>.
dave2wave commented on issue #388:
URL: https://github.com/apache/tooling-trusted-releases/issues/388#issuecomment-3621083190
#391 includes example version patterns across the industry
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Clarify and constrain permitted ASF TLP version numbers (tooling-trusted-releases)
Posted by "dave2wave (via GitHub)" <gi...@apache.org>.
dave2wave commented on issue #388:
URL: https://github.com/apache/tooling-trusted-releases/issues/388#issuecomment-3712035088
@sbp this is ready for your review by Wednesday
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Clarify and constrain permitted ASF TLP version numbers (tooling-trusted-releases)
Posted by "dave2wave (via GitHub)" <gi...@apache.org>.
dave2wave commented on issue #388:
URL: https://github.com/apache/tooling-trusted-releases/issues/388#issuecomment-4087556614
We start work on this with #912
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Clarify and constrain permitted ASF TLP version numbers (tooling-trusted-releases)
Posted by "sbp (via GitHub)" <gi...@apache.org>.
sbp commented on issue #388:
URL: https://github.com/apache/tooling-trusted-releases/issues/388#issuecomment-3730363866
We already have code in ATR that performs filename analysis here:
https://github.com/apache/tooling-trusted-releases/blob/main/atr/analysis.py
We can try to extend that code to cope with these edge cases.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Clarify and constrain permitted ASF TLP version numbers (tooling-trusted-releases)
Posted by "dave2wave (via GitHub)" <gi...@apache.org>.
dave2wave commented on issue #388:
URL: https://github.com/apache/tooling-trusted-releases/issues/388#issuecomment-3752555341
Going back to the original question: There is evidence of project releasing Apache Foo 3.2.1-RC1, Apache Foo 3.2.1-RC2, and Apache Foo 3.2.1 officially and in sequence.
We need to allow such forms as official releases... and deal with any consequences as they occur.
Let's extract an actionable issue around pattern detection for release version strings and how that applies to cataloging release lifecycles.
Part of aligning the release version string with a pattern is we catch an intentional "-RC1" as a release.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Clarify and constrain permitted ASF TLP version numbers (tooling-trusted-releases)
Posted by "sbp (via GitHub)" <gi...@apache.org>.
sbp commented on issue #388:
URL: https://github.com/apache/tooling-trusted-releases/issues/388#issuecomment-3607716106
Ah, thanks for clarifying. So it's a terminology distinction: on the one hand **release candidates**, which are not approved by a PMC and not distributed to the public; and on the other hand **alpha, beta, and milestone releases**, which are approved by a PMC and distributed to the public. But that doesn't explain why there are `(?i)rc[0-9]+` releases such as Apache Lucene.NET 3.0.3-RC2:
https://dist.apache.org/repos/dist/release/lucenenet/3.0.3-RC2/
Perhaps these are considered alpha releases? In other words, what is the coupling of version number components to the release status grades in our release policy? Is it possible to release with "RC2" in the name despite the terminology "release candidate" being reserved in the release policy for unapproved, non-public releases?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Clarify and constrain permitted ASF TLP version numbers (tooling-trusted-releases)
Posted by "raboof (via GitHub)" <gi...@apache.org>.
raboof commented on issue #388:
URL: https://github.com/apache/tooling-trusted-releases/issues/388#issuecomment-3607888071
> So it's a terminology distinction: on the one hand **release candidates**, which are not approved by a PMC and not distributed to the public; and on the other hand **alpha, beta, and milestone releases**, which are approved by a PMC and distributed to the public.
It's possible that different PMCs use different terminology: it's possible that one PMC makes 'alpha' packages that are only meant for use internally to contributors/developers and are not voted on (i.e. "not real Releases"), while another PMC makes 'alpha' packages that _are_ voted on and suitable for (bleeding-edge) developers outside of the project (i.e. "real Releases"). The main distinction is that if it's gone through the full release process (including vote) it's a "real Release", and if it's not, it's not.
> what is the coupling of version number components to the release status grades in our release policy? Is it possible to release with "RC2" in the name despite the terminology "release candidate" being reserved in the release policy for unapproved, non-public releases?
I think the point is kind of moot: while I could go either way on whether I think the release policy forbids referring to the RC as "RC" after the vote has passed, in any case it's confusing and we shouldn't do that.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Clarify and constrain permitted ASF TLP version numbers (tooling-trusted-releases)
Posted by "dave2wave (via GitHub)" <gi...@apache.org>.
dave2wave commented on issue #388:
URL: https://github.com/apache/tooling-trusted-releases/issues/388#issuecomment-3684259089
Related to #222
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Clarify and constrain permitted ASF TLP version numbers (tooling-trusted-releases)
Posted by "sbp (via GitHub)" <gi...@apache.org>.
sbp commented on issue #388:
URL: https://github.com/apache/tooling-trusted-releases/issues/388#issuecomment-3607983531
> I think the point is kind of moot: while I could go either way on whether I think the release policy forbids referring to the RC as "RC" after the vote has passed, in any case it's confusing and we shouldn't do that.
Agreed. I think what I might do is add a JavaScript check to the page to start a release, on the form where you have to enter the version, and if it detects an rc-style tag in there it warns and documents why that's potentially a bad idea. Then the release manager is made explicitly aware of what they're deciding to do, and how ATR works.
Alternatives considered: adding a check, and forbidding rc-style tags entirely. We can't add a check for this because checks only apply to files within a release. Those might have rc-style tags too, of course, but we actually _allow_ those tags in filenames because they can be removed before release. Also, the version cannot be changed after a release has started without deleting the whole release and starting again. We could forbid rc-style tags entirely, as I suggested above, but if the release manager is making an explicit choice even after we've documented exactly why rc-style tags should not be used for a finished release then there's probably an important reason for that and we'd at least know who the release managers are that we need to discuss this with.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Clarify and constrain permitted ASF TLP version numbers (tooling-trusted-releases)
Posted by "raboof (via GitHub)" <gi...@apache.org>.
raboof commented on issue #388:
URL: https://github.com/apache/tooling-trusted-releases/issues/388#issuecomment-3607775495
If anything, it is incredibly confusing 😆. I'm not too familiar with the Lucene.Net, but what I'd _suspect_ has happened is that they first voted on an RC1, that vote failed, then they voted on RC2, that vote succeeded, and they just plopped the RC2 artifacts into the 'dist' folder without renaming them. That is not "wrong" - by passing the vote this RC is no longer just an RC but a "real Release" - but not having the name reflect that is of course confusing.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Clarify and constrain permitted ASF TLP version numbers (tooling-trusted-releases)
Posted by "raboof (via GitHub)" <gi...@apache.org>.
raboof commented on issue #388:
URL: https://github.com/apache/tooling-trusted-releases/issues/388#issuecomment-3607797317
If so this would be an excellent example where hopefully the guidance of ATR would help them vote on the RC artifacts, and then after voting move them to the dist area while dropping the RC annotation ;)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Clarify and constrain permitted ASF TLP version numbers (tooling-trusted-releases)
Posted by "dave2wave (via GitHub)" <gi...@apache.org>.
dave2wave commented on issue #388:
URL: https://github.com/apache/tooling-trusted-releases/issues/388#issuecomment-3702883085
Some version matching code from ChatGPT that should work for all the observed paths I've seen. Will need extension for cases with both a Scala version and release version.
See https://chatgpt.com/s/t_69558cae4ee48191888f1ed42cc8ada8
Below is a **small, clean extension** of the existing API that returns the **unmatched prefix and suffix** around the detected token, while preserving all prior guarantees:
* ✅ calendar-accurate dates
* ✅ date beats version
* ✅ no overlaps
* ✅ named capture groups
* ✅ consistent separators
---
## Returned structure
```python
{
"kind": "date" | "version",
"value": "matched token",
"prefix": "text before match",
"suffix": "text after match",
"match": re.Match,
}
```
---
## Updated implementation
```python
import re
from typing import Optional, Match, Literal, TypedDict
from datetime import date
class VersionDateMatch(TypedDict):
kind: Literal["date", "version"]
value: str
prefix: str
suffix: str
match: Match[str]
# ---------------------------
# DATE REGEX (structure only)
# ---------------------------
DATE_PATTERN = re.compile(
r"""
(?<!\d)
(?P<date>
(?P<year>[12]\d{3})
(?:
(?P<sep>[._-])
(?P<month>0[1-9]|1[0-2])
(?:
(?P=sep)
(?P<day>0[1-9]|[12]\d|3[01])
)?
)?
)
(?!\d)
""",
re.VERBOSE,
)
# ---------------------------
# VERSION REGEX
# ---------------------------
VERSION_PATTERN = re.compile(
r"""
(?<!\d)
(?P<version>
(?P<major>0|[1-9]\d*)
(?:
(?P<sep>[._-])
(?P<minor>0|[1-9]\d*)
(?:
(?P=sep)
(?P<patch>0|[1-9]\d*)
(?:
(?P=sep)
(?P<build>0|[1-9]\d*)
)?
)?
)?
)
(?!\d)
""",
re.VERBOSE,
)
```
---
## Calendar validation helper (unchanged)
```python
def _is_valid_calendar_date(
year: int,
month: Optional[int],
day: Optional[int],
) -> bool:
try:
if month is None:
return True
if day is None:
date(year, month, 1)
return True
date(year, month, day)
return True
except ValueError:
return False
```
---
## Public API (with prefix/suffix)
```python
def find_version_or_date(text: str) -> Optional[VersionDateMatch]:
"""
Find the first calendar-valid date or version token and return
the unmatched prefix and suffix text.
Returns
-------
VersionDateMatch | None
"""
# 1️⃣ Dates first (non-overlapping)
for m in DATE_PATTERN.finditer(text):
year = int(m.group("year"))
month = int(m.group("month")) if m.group("month") else None
day = int(m.group("day")) if m.group("day") else None
if _is_valid_calendar_date(year, month, day):
return {
"kind": "date",
"value": m.group("date"),
"prefix": text[: m.start()],
"suffix": text[m.end() :],
"match": m,
}
# 2️⃣ Versions fallback
m = VERSION_PATTERN.search(text)
if m:
return {
"kind": "version",
"value": m.group("version"),
"prefix": text[: m.start()],
"suffix": text[m.end() :],
"match": m,
}
return None
```
---
## Examples / Tests (prefix & suffix)
```python
tests = [
"release-2024-02-29-final",
"v1.2.3",
"prefix_2025_12_suffix",
"build.0.9.1-rc1",
"2025.12.1", # invalid date → version
]
for t in tests:
r = find_version_or_date(t)
if r:
print(
f"{t!r}\n"
f" kind : {r['kind']}\n"
f" value : {r['value']}\n"
f" prefix : {r['prefix']!r}\n"
f" suffix : {r['suffix']!r}\n"
)
else:
print(f"{t!r} -> None\n")
```
### Expected output (conceptual)
```
'release-2024-02-29-final'
kind : date
value : 2024-02-29
prefix : 'release-'
suffix : '-final'
'v1.2.3'
kind : version
value : 1.2.3
prefix : 'v'
suffix : ''
'prefix_2025_12_suffix'
kind : date
value : 2025_12
prefix : 'prefix_'
suffix : '_suffix'
'build.0.9.1-rc1'
kind : version
value : 0.9.1
prefix : 'build.'
suffix : '-rc1'
'2025.12.1'
kind : version
value : 2025.12.1
prefix : ''
suffix : ''
```
---
## Why this is useful
* Enables **rewriting**, **normalization**, or **templating**
* Ideal for build systems, release tooling, and APIs
* Prefix/suffix logic avoids fragile string slicing elsewhere
If you want:
* multiple matches with spans
* replace/normalize APIs
* strict ISO formatting output
* performance tuning for large inputs
I can extend this cleanly.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Clarify and constrain permitted ASF TLP version numbers (tooling-trusted-releases)
Posted by "dave2wave (via GitHub)" <gi...@apache.org>.
dave2wave commented on issue #388:
URL: https://github.com/apache/tooling-trusted-releases/issues/388#issuecomment-3739583552
I think we need to step back and separate the use cases.
1. Validating and parameterizing the version string provided during the **start a release** form.
2. Validating that artifact filenames follow naming rules and resolve to an identifiable file type.
3. Auto-tagging artifacts based on both naming rules and pattern matching.
There are two flavors to these checks: (a) checking release candidates and (b) collating historical releases from various sources.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Clarify and constrain permitted ASF TLP version numbers (tooling-trusted-releases)
Posted by "sbp (via GitHub)" <gi...@apache.org>.
sbp commented on issue #388:
URL: https://github.com/apache/tooling-trusted-releases/issues/388#issuecomment-3730358329
Sorry for the delay. Here are some Scala specific patterns that I found:
* `release/doris/spark-connector/1.1.0/apache-doris-spark-connector-3.2_2.12-1.1.0-src.tar.gz` (`2.12` is the Scala version; `3.2` is the Spark version and `1.1.0` is the connector version)
* `release/flink/flink-1.18.1/flink-1.18.1-bin-scala_2.12.tgz` (`scala_2.12` is the Scala version)
* `release/incubator/livy/0.8.0-incubating/apache-livy-0.8.0-incubating_2.12-bin.zip` (`2.12` is the Scala version)
* `release/kafka/3.9.0/kafka_2.12-3.9.0.tgz` (`2.12` is the Scala version)
* `release/spark/spark-3.5.5/spark-3.5.5-bin-hadoop3-scala2.13.tgz` (`scala2.13` is the Scala version)
And some other paths with multiple version numbers:
* `release/carbondata/2.2.0/apache-carbondata-2.2.0-bin-spark3.1.1-hadoop2.7.2.jar` (Carbondata, Spark, and Hadoop versions respectively)
* `release/flink/flink-1.19.2/python/apache_flink-1.19.2-cp311-cp311-macosx_11_0_arm64.whl` (Flink, CPython, CPython, and macOS versions respectively)
* `release/flink/flink-table-store-0.3.0/flink-table-store-hive-connector-0.3.0_3.1.jar` (Connector and Hive versions respectively)
This is just a selection of the most interesting.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Clarify and constrain permitted ASF TLP version numbers (tooling-trusted-releases)
Posted by "raboof (via GitHub)" <gi...@apache.org>.
raboof commented on issue #388:
URL: https://github.com/apache/tooling-trusted-releases/issues/388#issuecomment-3607664774
> This may imply that TLPs have some kind of need that is not covered by the release policy, or that they are unaware of this part of the policy
The distinction the release policy is making is between "real Releases" and "not real Releases": "real Releases" are things that have been properly voted on by the PMC, "not real Releases" are all other things - the "raw source repositories, nightly builds, snapshots, release candidates, or any other similar packages".
As an example, Pekko is currently voting on `2.0.0-M1-RC1`, and if this vote passes, this code will be released as `2.0.0-M1`. The fact that this version ends in `-M1` does not imply that it is a "not real Release", it is the other way around: the fact that we have properly voted on it as PMC makes it a "real Release". This is in line with the release policy - it does not forbid "version numbers which appear to contain a pre-release component" - for example the last bullet in https://www.apache.org/legal/release-policy.html#release-types explicitly highlights "real Releases" that are nonetheless "milestones intended only for bleeding-edge developers working outside the project".
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org
Re: [I] Clarify and constrain permitted ASF TLP version numbers (tooling-trusted-releases)
Posted by "dave2wave (via GitHub)" <gi...@apache.org>.
dave2wave commented on issue #388:
URL: https://github.com/apache/tooling-trusted-releases/issues/388#issuecomment-3608348872
If we going to disallow RC naming in the version name then we have to convince legal to modify Release Policy. I think we are ready to make a list of changes to policy we wish to propose.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tooling.apache.org
For additional commands, e-mail: dev-help@tooling.apache.org