Add comments here.
This page should talk about a provision for dealing with major version number changes that impact applications which use LSB-specified shell programs. It should probably state that shell scripts can query the distribution to see which versions are supported via the lsb_release command. However, this is not sufficient to provide backwards compatibility if we need to make incompatible changes in the future. (For example, if LSB 4.0 makes changes that brings it into closer alignment to POSIX.) This can be done by requiring the hypothetical LSB 4.0 application to declare the fact that they are expecting the LSB 4.0 behavior. (For example, we might require that all LSB 4.0 applications define some environment variable that changes the behavior of the shell programs, so that the LSB 2.0 and 3.0 applications still get the same default behavior, but LSB 4.0 get the new, POSIX-aligned behavior. This could be done via defining a environment variable such as POSIXLY_CORRECT, for example.) The important point is that if we want to make changes to how the shell programs function, and we also want to allow distributions to be simultaneously certify against LSB 3.0 and 4.0, it will be important that we remember to require LSB 4.0 application to identify themselves so that the shell commands can simultaneously satisfy both the LSB 2.0/3.0 and LSB 4.0.
--Theodore Tso, 2/24/2005
Good point, changing shell/command level behavior doesn't have a decent scheme for coexistence. Do we really envision that much changing, though?
One of the reasons that things might change would be for Posix alignment --- if for example the upstream agrees (or decides to) make changes to brings us closer to POSIX.2, for example. We should make sure that we a document a plan so we can handle such changes, or other ones that might we can't forsee right now. It's just one of those things that require forethought, and I believe I have outlined one way of allowing coexistence above. The important thing is that we be able to tell people that we have a plan that allows coexistence and forwards compatibility for all parts of the standard, not just the C ABI portion. --Theodore Tso, 2/26/2005
There are some additional comments in bug 726