Fernando de Oliveira wrote: > --- Em seg, 1/10/12, BLFS Trac escreveu: >> Changes (by bdubbs@…): >> >> * status: new => closed >> * resolution: => wontfix >> >> >> Comment: >> >> I'm going to mark this as wontfix. IM manages to do a >> sub-point >> (major.minor.point-subpoint) release way too often. >> It feels like once a >> week. We already have a note in the book about the >> frequent updates and >> the user can check for a newer version. >> >> Lets just update at point releases or higher.
> I understand and agree. I created the ticket without installing it, too. > The objective was to follow the upgrades untill feeling it was time to do > it. > > I liked your decision to follow just point upgrades, instead of having to > wait for "someday one has time to do it...". Therefore, next will be > 6.7.10-0, or 6.7.10-8, just to keep the cicle with current in the book? > Perhaps 6.7.10-0, and then only next point release? Yes, 6.7.10.x, 6.7.11.x or 6.8.x.x, etc. <rant> I'm getting a bit tired of some of these packages developers that don't really understand software engineering. One major task for version control is for developers to put in changes and let things percolate so QA or others in the development process can test things out. Making a release once a week and letting the community report problems reflects poorly on the developers. Other packages that seem to fall into the same trap are git, systemd, and even the kernel.</rant> There are major packages seem to do a lot better: glibc, gcc, xorg, kde, gnome, apache, bind, binutils, util-linux, etc. Unless there are major security flaws, once every six months seems about right. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
