Meeting minutes
Organizational
Minutes
<Ege> https://
Ege: No objections -> minutes approved
TTWG registry analysis
Ege: see w3c/
… ask for volunteer
… M.Koster and I can deal with it
Resource Management
Ege: see w3c/
<Ege> https://
<mm> (ntd in 30m hopefully we can get through the versioning by then)
Ege: we want to agree on part "until REC release"
… 2 open points
… moreover, we should look at "changelog" section
Open point 1: Decide whether we want a simple integer or a date after the pre
<kaz> [[ date, "-", number, e.g., "2.0.0-pre20240301-1+td-2.0.0-pre20240301-1" (posibly use "." instead of "-") ]]
McCool: proposal for date vs sequence number
… propose to do both
… normally we just have 1 number.. but helps in case of PlugFests
McCool: number starts every day ... but normally it is just one
<luca_barbato> +1 for . separator
Ege: Number for flexibility reason
… other reason is communication with other human
Kaz: The content is fine and reasonable.. anyhow.. description seems complicated
… we might want to fix the prose
Ege: I see
Cristiano: I am ok with current format
… should the "-1" always be there.. even if there is just one release
McCool: Yes
Ege: Cristiano, what do you prefer?
Cristiano: using "date" might be better.. even though it is longer
… just number is okay also
Luca: fine with approach
… propose to have many releases
… as separator I prefer dot over dash
… btw, date can be tuned by adding hour etc
Luca: time reference in version is nice to reason
… adding sequence number is similar to adding hour
Luca: alternative to use portions only if needed
McCool: I prefer day granularity
… sequence number is better than hour ... during TestFests etc
… i still prefer dayDate + sequenceNr
<cris1> +1 for `.`
Kaz: Discussion is important and delicate
… should minute the proposal
<Ege> [[ date, "." , number, e.g., "2.0.0-pre20240301.1+td-2.0.0-pre20240301.1" ]]
<mm> (really three main proposals: (1) date (day granuaritly), (2) sequence number, or (3) both)
Daniel: prefer well defined format.. not adding portions when needed only
McCool: prefer mixed format
Ege: Is everybody fine with the following format?
<mm> +1 for not changing granularity - fixed day granularity to keep things simplish.
Kaz: I'm OK with the updated notation, but we should document what "-" and "." mean here, e.g., "-" to show the separation of modules and "." to show the separation within each module.
Ege: Right. We need to document that as part of the policy.
Luca: fine with current proposal.. seems simpler..
… there is enough agreement
… w.r.t. changelog ... we can generate it from commits
<Ege> proposal: using the following in pre REC release for the version number of all resources(semver for resource)-pre(date with day).(sequence number)+(spec version)-pre(date with day).(sequence number)
RESOLUTION: using the following in pre REC release for the version number of all resources: (semver for resource)-pre(date with day).(sequence number)+(spec version)-pre(date with day).(sequence number)
Ege: Perfect, will update PR accordingly
Kaz: Minor: the "Archive" section at the bottom should be removed
… at least for the final version
… we can still keep for a while, but should describe that "Archive" section is a record of discussions during the TD calls.
Ege: Yes, will remove it later (and adds description about the archive for now)
Open point 2: Whenever needed or monthly
Ege: What about the regular releases?
… monthly or when needed?
McCool: Whenever needed
McCool: micro PRs should not create releases
Daniel: Agree, whenever needed makes sense
Luca: As long we have the machinery ready ... it is fine to create artifacts when needed
… anyhow, does not provide regularity
Kaz: Minor comment: "title open point 2" should not be changed today
Kaz: General: we should record all changes
Kaz: ... need mechanism to track all the changes
Kaz: Small PRs are fine
Ege: Any objection to work with commits and PRs?
Luca: branches are working areas.. merge commit is the actual change (log)
… for changelog we need merge or squash commits
Ege: agree to use conv. commit messages
Cristiano: +1 for current proposal to release as often as possible
<Ege> proposal: We should consider a release after a resource-targeting PR but we can skip some if see the need
<dape:> +1
<Ege> proposal: We should consider a release after a resource-targeting PR but we can skip some if we see the need
RESOLUTION: We should consider a release after a resource-targeting PR but we can skip some if we see the need
Ege: <updating VERSIONING.md>
Kaz: Need to clarify the exceptions
… not today, though
Ege: Agree
Changelog
Ege: I would go to "changelog" dicussion
… we talked about it already a bit
… in discovery TF changelog is used already
Ege: First question: Where is the changelog?
… outside html or Markdown
… not sure about tooling
Ege: other point. Should it be relative difference ?
… diff to previous release ?
… w.r.t. automation ... we should give it a try
Cristiano: scope in conventional comment might help
… I used that in the past and it worked
… about auto-changes ... tool can be instructed to do the diff/changelog based on last official release
Cristiano: conventional commit is useful .. but sometimes the "type" of change is not easy...
Ege: one commit message for a multiple set of changes in different resources
Cristiano: doing separate commits does not make sense
Luca: If we generate different changelog for each artifact ...
… we do not work on software commits
Kaz: We should continue the discussion next time since we are out of time. However, let's record important point as "Open points" on the VERSIONING.md.
… we also need to think why we need changelog
… basically, we'd like to provide information to external developers so that they can tell what was changed when. We need to consider that when we continue the discussion.
<kaz> Open points on Changelogs:
<kaz> * Guideline for commit messages
<kaz> * Should there be one changelog file or per resource?
<kaz> * Clarify the goal of the changelog. For now, it is
<kaz> [adjourned]