Bug 489626

+1

I use numbers in titles for relnotes. In MRG, any books (mostly relnotes) released for minor releases (x.y.z) get collapsed into the major release's directory (x.y). This means we need to able to specify which minor release the book is for. We can't have four books all titled "Release Notes" floating around in one directory. Using other naming conventions ("Release Notes Security Release"; "Release Notes Enhancement Release") is not only confusing for the customer and the maintainer, but also very limited in scope (When you already have a "Release Notes Security Release" for 1.1.1, what do you call the security release for 1.1.4?).

</$0.02>

LKB

(In reply to comment #1)
> +1
> 
> I use numbers in titles for relnotes. In MRG, any books (mostly relnotes)
> released for minor releases (x.y.z) get collapsed into the major release's
> directory (x.y). This means we need to able to specify which minor release the
> book is for. We can't have four books all titled "Release Notes" floating
> around in one directory. Using other naming conventions ("Release Notes
> Security Release"; "Release Notes Enhancement Release") is not only confusing
> for the customer and the maintainer, but also very limited in scope (When you
> already have a "Release Notes Security Release" for 1.1.1, what do you call the
> security release for 1.1.4?).
> 
> </$0.02>
> 
> LKB  

Changing the name (title) for each revision means that users of the Desktop content will NOT get updated documentation when they upgrade because you are changing the package name.

---

e.g.

I install version 1.0 of foo + foo-release-notes

I upgrade to foo 1.1; the release notes didn't get updated because the package name changed and I don't have the renamed package installed. Now the release notes I'm reading are out of synch with the program.

---

In addition you are going to be incurring an increasing maintenance burden every z stream release. Each package you ship has to be maintained for 7 years, and because you are effectively forking the package every Z stream, that is one more package on your list for the next 7 years.

This scenario is the reason this restriction was introduced. Over time it creates a massive, ongoing, unavoidable maintenance effort. Do you really want to have 7 versions of your release notes package in Bugzilla and have to port fixes between them?

However, there are good reasons for allowing numbers in titles. Isaac, Brian and I cornered Mike and have this policy changed, so a patched version will be coming out soon.

I'd seriously reconsider using this facility for the use you specified above.

Cheers, Jeff.

Jeff,

I really don't understand the point you're trying to make here. Why would having numbers in the title prevent users from getting the package? It appears as though they wouldn't get the package regardless, from your example. Also, as far as packages go, surely the package exists regardless of its title, and therefore needs maintenance?

Sorry, I'm not trying to be facetious, I just don't understand, and would like to. If there's a better way of doing things, then I'm all for it!

L

(In reply to comment #3)
> Jeff,
> 
> I really don't understand the point you're trying to make here. Why would
> having numbers in the title prevent users from getting the package?

It's about upgrading, when you change the name you have a new package; so they don't get updated content when they run yum update.

> It appears
> as though they wouldn't get the package regardless, from your example.

"I install version 1.0 of foo + foo-release-notes" where foo-release-notes is your docs package.

> Also, as
> far as packages go, surely the package exists regardless of its title, and
> therefore needs maintenance?

If you update the content without changing the name you have 1 package to maintain, and you are actively maintaining it every release. If you rename it you have many packages to maintain and you have to ensure you back port any relevant fixes.

Cheers, Jeff.

So you're suggesting that we should have one relnote per x.y release, and just change the content of it for every x.y.z release?

Doesn't that cause a major problem with historical reference? What about if someone is running foo 1.1.1 and the only available relnotes are for foo 1.1.3 (Because the 1.1.1 relnotes got updated to 1.1.2 and then 1.1.3)?

What about the circumstance where someone updates to 1.1.2, finds issues and rolls back to 1.1.1? How do they find out what potential issues they may be rediscovering by doing that?

As for maintenance, they're relnotes - by definition, they only apply for that release (minor or otherwise), so there's not really an ongoing maintenance issue. I can see where the problem might lie in doing that with books, but that's why I don't do books like that ;)

Unless I've completely missed your point (again)?

L

publican-fedora-0.18-0.fc10,publican-0.44-0.fc10 has been submitted as an update for Fedora 10.
http://admin.fedoraproject.org/updates/publican-fedora-0.18-0.fc10,publican-0.44-0.fc10

publican-fedora-0.18-0.fc10, publican-0.44-0.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.