| 1 |
On Tuesday, 10 October 2017 11:46:22 BST Neil Bothwick wrote: |
| 2 |
> On Mon, 9 Oct 2017 19:20:53 +0000 (UTC), Grant Edwards wrote: |
| 3 |
> > It turns out that over the past week or so, there have been several |
| 4 |
> > |
| 5 |
> > _different_ firefox ebuilds released. One of them was broken: |
| 6 |
> > Version 52.4.0 (Oct 3) was OK. |
| 7 |
> > |
| 8 |
> > Version 52.4.0 (Oct 7) was broken. |
| 9 |
> > |
| 10 |
> > Version 52.4.0 (Oct 9) is OK. |
| 11 |
> > |
| 12 |
> > You (and I) had successfully installed the Oct 3 version of 52.4.0, |
| 13 |
> > but when I tried to install the Oct 7 version of 52.4.0, it failed. |
| 14 |
> > The Oct 9 version is supposed to be fixed. I don't really see how you |
| 15 |
> > can repeatedly release new versions of something without changing the |
| 16 |
> > version number, but maybe that's just me... |
| 17 |
> |
| 18 |
> It depends on the breakage. If the installed program is broken it should |
| 19 |
> be bumped, but if the breakage only relates to the build in some |
| 20 |
> circumstances, it makes sense not to bump it. Otherwise everyone that |
| 21 |
> installed the first time, maybe because they had the necessary |
| 22 |
> dependencies already, would have to re-emerge the package another two |
| 23 |
> times for no benefit. |
| 24 |
> |
| 25 |
> If they truly were new versions it would be different, but all the ebuilds |
| 26 |
> resulted in the same version of the software being installed. |
| 27 |
|
| 28 |
I see what you mean, but in that case the development management model is |
| 29 |
broken. It's sacrificing correctness and rigour to convenience. It needs a |
| 30 |
review at the highest level. What's called Management in ISO9000. |
| 31 |
|
| 32 |
-- |
| 33 |
Regards, |
| 34 |
Peter. |
Archives