This Time Self-Hosted
dark mode light mode Search

My idea of a pre-release

So, after the whole rant about the pre-release handling of KDE, I think I should also give an explanation of what I think pre-releases should have been used for.

The first and most obvious thing is of course testing if the problem fixing was actually problem fixing, rather than breaking something during the process, as that might easily happen, the latter is updating the requirements of distributions. Like Tobias Powalowksi from Arch Linux found, the new KDE 3.5.4 will require either eject 2.0.x or >=2.1.5, as the whole set between 2.1.0 and 2.1.4 are not working correctly with our HAL setup. As an alternative, also unieject works, but I’m not keen on forcing everyone to move to unieject now.

The other thing this time can be used for is to build the actual binary packages, not to distribute them, but at least to build. It takes more time to build binary packages for wide ranges of architecture respect to updating the ebuilds, and as I know also updating the ebuilds isn’t something that takes no time, if the binary packages are supposed to be released together with the official announcement of sources, they need to be prepared in advance; this is what a pre-release can be used for.

But then, this is not what it’s used by some people it seems. Although I can understand wanting to provide your experimenting users the latest and the best, either it’s decided to make it available or it’s secret… you want it done as soon as possible? Release the source officially, and wait for the announcement, that would work too.

But don’t make stuff officially pre-release only for developers, and then leave “the big ones” to go away with releasing stuff whenever they feel like it.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.