Hello Uwe
On Mon, Jan 14, 2013 at 2:33 AM, Uwe Stöhr <uwesto...@web.de> wrote: >> The Windows installer is your business. > > That is not fair. We can assume that at least 50% of our users use LyX on > Windows. > This is harsh reasoning. In many cases open-source projects only take responsibility for providing source-code that compiles and works as expected on various platforms. Packaging is more treated as a user-provided contribution (distro package managers for Linux, users for Windows and Mac). If it weren't for all your efforts, chances are that we wouldn't have an up-to-date Windows installer. But the project would definitely continue and new releases trickle in. > OK for them. Of course everybody can use what he wants but we should provide > an up to date LyX. Only this way people who wants or needs to use the latest > version can do so. People who wants to stay with e.g. teTeX can do this, but > need an appropriate LyX - I would say LyX 1.5.x. > As mentioned earlier several times, updating LaTeX packages on Linux is only for experts. And even then, they wouldn't necessarily want to bother with the effort. Cutting off a significant proportion of users (many academics and hackers seem to be using Ubuntu and other distros, among other OSes) and developers (off the top of my head, most of our developers work on Linux or some *nix flavour) seems like a very bad idea. We wouldn't want JMarc to be unable to use latest LyX (release, branch or trunk), would we? I didn't follow all the details, but if the layout naming scheme allows enough flexibility to provide layout updates during minor releases, but keeps old documents created within the same major release cycle to compile (whatever the minor release being used by the user, 2.0.1 or 2.0.5), then this is definitely the way to go. Even if it means more workload and a different workflow for the maintainer. And finally, as was explained on earlier occasions, minor releases strive to keep a stable file format. This is a long-time LyX policy. If previously file format changes happened on a minor release, then that was bad policy policing. And that was inconsistent. The idea is that a user should be able to interchange 2.0.1, 2.0.3 and 2.0.9 seamlessly, without worrying whether a document will fail to compile on any of these releases. I think that one issue with our release cycle is that it is painfully (if understandably) slow. It usually takes a minimum of 3 months between minor releases, and some two years between major releases. This would partly explain why some would come to think of minor releases (e.g., 2.0.5) as major releases (which they aren't). Regards Liviu
