Meeting minutes
minutes review from March 21
<kaz> Mar-14
Ege: Any issues or comments on the minutes?
<mm> (note: changing my nick to mm rather than McCool...)
Ege: Minutes from March 21 are approved
Versioning
Ege: today we are working on resources and there is a PR
<Ege> https://
<Ege> PR 1969 - WIP: Concrete Versioning Proposal
Ege: the PR is about management and versioning of resources
Ege: we are not planning to version the 1.0 or 1.1 specification because there is no existing version policy, so we are starting with the td.next version
Ege: reviews the requirements for versioning
Kaz: we should be clear the document refers to td.next
McCool: it should be for all WoT specifications
Kaz: currently, the title of the document says "Versioning of TD Specification Resources", so it would be better to say "Versioning for this Charter Period Resources" then.
Ege: (changes the section title accordingly)
McCool: we should explicitly include testers in the requirements
Ege: early adopters includes anyone who uses WoT before the release
McCool: we don't want to make changes without updating the version number, so we should be clear that any change requires a version update
Ege: any objections to this?
Ege: agreed
Ege: not everything in the proposed policy is agreed
Kaz: we should consider how to deal with editorial changes and tooling changes also
Ege: there is a section for tooling
Ege: the first point is that the version is coded into the resource itself, how to do this is not specified yet
Ege: before release, we use snapshot identifiers but not major/minor/patch until release
Ege: there will be explicit pre release version identifiers with the format described in the proposal
McCool: wanted to clarify that there is a separate scheme for pre releases
Kaz: the basic flow looks OK, but there are some uncertainty. We need to explain the pre-release and post-release policies more clearly. the section title "Decisions" is also misleading, and to be clarified by some more additional description.
David: In the examples, does 2.0.0. refer to the old or the new spec version
Ege: it is the target spec number
David: The open issue is how to version documents that don't change
Ege: the policy is all the the dependent documents will change version number
<Zakim> dezell, you wanted to ask about pending "jumps"
David: we should also specify the exact pre-release version format so everyone does the same thing
McCool: if tooling creates the pre-release number, it will be consistent
McCool: the date style is easier and less error-prone
<mm> (remembered my other point :)
Kaz: maybe we could add more fields to the version number to indicate the type of change
Ege: we decided to do this for versions after the release
Ege: does anyone have a preference for dates or sequence number?
Luca: the sequence number could be based on the month or week if we agree on regular releases
Luca: if we release code whenever it's needed we can use the date
Ege: to clarify, the number style is more appropriate for regular release schedule, and the data style is better for on-demand releases
Luca: recommend that we have regular releases and use a month or week number
McCool: it is helpful to have a date for more information, day granularity should be sufficient
Luca: a weekly release would fit well with our current track
McCool: weekly releases might be too much constraint, we may want to do frequent releases during testfest
McCool: day granularity could be OK< but not larger
McCool: one more point, we should consider versioning of resources outside the spec
Kaz: to clarify McCool's suggestion, is it a virtual specification you are proposing?
McCool: yes, we could invent a virtual specification
Kaz: with a string identifier
Ege: next to consider is the policy after release
Ege: after release, the resource versions are not synchronized
Ege: the reason is to avoid breaking the tooling
Ege: resources are versioned independently plus an identifier for the spec version
Ege: we define the meaning of changes based on JSON schema and Conexxus definitions
Ege: minor changes are things like adding keywords
Kaz: The section title in this document, Decisions, is really basic requirements or basic policy
Ege: OK, changed it
David: at Conexxus, we defined minor as a change that would surprise the receiver of TDs. One example of a surprise is changing the length of the TD
David: also adding a keyword is only minor for optional keywords
Ege: presents some examples of changes and resulting version strings
<kaz> examples
McCool: not clear how the resource version is coupled to the spec version after publication
Ege: will add a specific example
Kaz: can we assume we will publish only one version per day?
Ege: with this scheme we would be limited to one per day
Luca: we could add additional ISO datetime information if we need more than one per day
Luca: we can decide when it is needed, based on what is most comfortable for us
<mm> (time check - I need to drop soon)
<mm> (re variable time length - sure, we could do that, but complicated. We may as well use sequence numbers if we are going to do that)
<mm> (although as a compromise, we can use day granuarity, and add a sequence number for extra releases on the same day)
<mm> (e.g. 20240311.2)
Kaz: given the time, we can keep this point open for today and discuss later
Ege: reviews open points remaining
<kaz> open points
Kaz: given we're already at the top of the hour, let's continue the discussion next week.
McCool: I will commit to attending next Thursday to continue the discussion
David: can also come
Ege: thank you and adjourned
<kaz> [adjourned]