Keeping the version in filenames
Göran Weinholt
(01 Oct 2009 16:29 UTC)
|
Re: Keeping the version in filenames
Abdulaziz Ghuloum
(02 Oct 2009 05:53 UTC)
|
Re: Keeping the version in filenames
Göran Weinholt
(02 Oct 2009 12:59 UTC)
|
Re: Keeping the version in filenames
Derick Eddington
(02 Oct 2009 16:22 UTC)
|
Re: Keeping the version in filenames
Abdulaziz Ghuloum
(02 Oct 2009 17:24 UTC)
|
Re: Keeping the version in filenames
Derick Eddington
(02 Oct 2009 20:13 UTC)
|
Re: Keeping the version in filenames
Abdulaziz Ghuloum
(02 Oct 2009 16:51 UTC)
|
Re: Keeping the version in filenames
Derick Eddington
(02 Oct 2009 20:25 UTC)
|
Re: Keeping the version in filenames Derick Eddington (02 Oct 2009 13:06 UTC)
|
Re: Keeping the version in filenames
Abdulaziz Ghuloum
(02 Oct 2009 16:26 UTC)
|
Bye-bye versioning
Derick Eddington
(02 Oct 2009 19:56 UTC)
|
On Thu, 2009-10-01 at 17:59 +0200, Göran Weinholt wrote: > I'm wondering what my workflow will look like if I want to write > libraries that work with SRFI-103. Thanks for your feedback. > Since I have versions in all my > library forms, it seems like I'd have to rename my files whenever I > change a version number. Yes, that's true. > I would need to write a save-hook or it would > get boring pretty fast. I suspect that I'd also need to abandon the > YYYYMMDD part of my version numbers, or I'd end up with quite a lot of > files. You'd need to rename the files via the repository manager so it tracks the renaming and gets rid of the old file name. I look at the issue like this: This SRFI needs to support having multiple versions of a library stored as separate files in the same directory. The only way to accomplish that is by having versions in file names. It is important to support having multiple versions available so that different programs which require different versions can both be used. If the file naming scheme does not support versions, the only way to accomplish running the different programs is to manage configuring the search paths used for each program so that the correct version is used. We should be able to know what libraries are present, which includes knowing their versions because different versions are distinct things, from only a listing of file names. The only way to accomplish that is by having versions in file names. A library's file's name should represent the library's name, and a version is naturally a part of the name. The purpose of the version is to identify a distinct library, and the purpose of the file name is to correspond to the identity of the library. If we want a library's name to have a version, and we want its file name to correspond to the library name, then shouldn't the file name have the version? I want to make sure everyone has thoroughly thought about these points before sacrificing the qualities of the current draft for the sake of not being annoyed by file renaming. > So is the idea that I would be keeping versioned filenames in my bazaar > repository, or would they be renamed to include a version by a package > manager? The idea is that no package manager should be required and you'd have versioned file names in basic tar-balls and repositories. The idea is that library file names exactly represent the name of the contained library. > Also, SCHEME_LIBRARY_SEARCH_PATHS is rather long. How about SLSPATH? SLSPATH is rather short, non-descriptive, and makes it seem like its value can only be a single path. I'm okay with SCHEME_LIBRARY_PATHS or SCHEME_PATHS. (I've always hated the Unix tradition of making public global variables' names be bizarrely truncated and non-descriptive, and always loved the Lisp tradition of proper, descriptive names for such variables. IMO, there's not a good reason why environment variables' names should follow Unix tradition...) -- : Derick ----------------------------------------------------------------