Rick and Bruce,
I would take a different approach to this, which is used in a lot of other software development. Regardless of the source for the software (user contributed package), Stata should invest in a way to implement some type of versioning/retrieval similar to what exists in other languages. For example, R uses the Debian package specification which makes it possible to have multiple versions of the same package installed on the same machine that are localized to the package using it as a dependency. Python has similar structure (requirements.txt is the typical name for such a file). I think Java probably has the best solution for these types of issues with Maven; in addition to being able to bound dependent libraries with your library - and specify the precise version of the library to use - there are also options that allow you to compile the source code under the assumption that a library will already exist on the end user’s machine.
I would argue that this type of functionality would be more flexible than just sorting on the distribution date, because it would allow testing development releases while still allowing a stable release to be available to all. I know not everyone in the Stata community thinks the same way about solving this problem, but figured it could be useful to at least start up the dialog about this topic again.
I would take a different approach to this, which is used in a lot of other software development. Regardless of the source for the software (user contributed package), Stata should invest in a way to implement some type of versioning/retrieval similar to what exists in other languages. For example, R uses the Debian package specification which makes it possible to have multiple versions of the same package installed on the same machine that are localized to the package using it as a dependency. Python has similar structure (requirements.txt is the typical name for such a file). I think Java probably has the best solution for these types of issues with Maven; in addition to being able to bound dependent libraries with your library - and specify the precise version of the library to use - there are also options that allow you to compile the source code under the assumption that a library will already exist on the end user’s machine.
I would argue that this type of functionality would be more flexible than just sorting on the distribution date, because it would allow testing development releases while still allowing a stable release to be available to all. I know not everyone in the Stata community thinks the same way about solving this problem, but figured it could be useful to at least start up the dialog about this topic again.
Comment