On Fri, 2005-12-30 at 07:39 -0600, Tommy Reynolds wrote:
Uttered "Paul W. Frields" stickster@gmail.com, spake thus:
I had an interesting thought about this, which is that rather than having a "version" and "release" attribute, only one of which is applicable for each type of revision, why not use a single "revnumber" attribute? For docs, this would be a version change, and for new package rolls it would be a release change. The latest version for the doc and the RPM would always be the "revnumber" attribute of the topmost role="doc" revision, and the RPM's release would always be the "revnumber" attribute of the topmost role="rpm" revision.
Which ever is easier to parse.
Personally, I prefer the two-attribute approach because that seems more parallel to the actual update process: just change the version and release, similar to what would be done to manually construct the SPEC file. The 'role="rpm"' seems a bit artificial to me; perhaps it's just NIH syndrome.
This seems counter-intuitive to me, since documents have a version, not a release -- any document change means a version change (or it should if the editor is doing his job). Meanwhile, RPMs have a release, and the version is tied to the document source inside. The RPM may change versions, but only in conjunction with a document source change. And documents may change versions several times without any release, as they are progressively edited -- especially now that we have the webtest host where drafts are rolled during the work-in-progress.
This might be just the occasion to move out of the attribute space and into the subelement space, thus:
<revision role="doc" date="2005-12-31"> <author worker="me"/> <revnumber dim="version">0.15</revnumber> <details>Style changes</details> </revision> <revision role="rpm" date="Sat Dec 31 2005"> <author worker="stickster"/> <revnumber dim="release">1</revnumber> <details>Update to 0.15</details> </revision>
But frankly, that doesn't get easier to parse for people, which I was under the impression was the whole point behind XML and DTDs. Plus it leaves wiggle room for valid but erroneous entries. We might be well-served by making the DTD do the work for us:
<docrevision date="2005-12-31" version="0.15"> <author worker="me"/> <details>Style changes</details> </docrevision> <pkgrevision date="Sat Dec 31 2005" release="1"> <author worker="me"/> <details>Update to 0.15</details> </pkgrevision>
This may be a case where it's good to sacrifice compactness on the altar of comprehensibility.
The only possible issue I see in the commit you made to rpm-info.dtd this evening is in requiring copyright holders to be workers. For example, Red Hat, Inc. and the Fedora Foundation won't fit that type of element, although one or both of them will certainly be copyright holders on several of our works. If we're not going to keep it as PCDATA, perhaps using subelements (worker|corp) might work. I think the KISS method, though, might dictate punting this one.
Oops, I forgot about corporate ownership. OK, I'll revert it. /me updates CVS Done!
Saw this, thanks. For some reason I'm getting your mail to the list really late, which is why my response is so delayed in real time.