-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Open
Labels
Description
we suggest to use cci.<date> in several cases:
- libraries which aren't doing official releases (or tags, snapshots, etc.) at all
- libraries that didn't do releases for a long time, but people need to use newer source code (with new features, bug fixes, etc.). NOTE : such libraries might be still in active development, just release didn't happen yet and not planned/expected in the nearest time (e.g. if library is about to release in few days, it might be better to wait rather introducing unofficial CCI-specific snapshot)
- libraries which were abandoned, with no active development, but still used/requested
how to choose what to use?
- if library is doing any sort of releases, then use that releases. the library might use version numbers, roman numbers, source control revisions, letters, code names, dates, etc. to indicate releases - just use whatever library uses (without cci. prefix), any versioning scheme is accepted
- if the library isn't doing releases, but has tags in its version control system (e.g. on GitHub, GitLab, BitBucket, GoogleCode, SourceForge, etc. or just in their own git/hg/svn/csv/bazaar/etc server), use that tags
- if the library isn't doing releases and tags, but provides snapshots (tarballs) on HTTP/FTP/whatever server, such as nightly/daily/whatever snapshots, use them
- if the library isn't doing anything of the above, grab some source and label it with date and cci. prefix, try to record the revision number (if possible). also, try to identify a stable source, e.g. if there are multiple branches in source control, try to identify the stable one (it might be
master,trunk,main,default,stable, etc.). try to reach to developers when in doubt. if they provide some sort of instruction on how to get stable sources, follow it. even within stable branch, it might be hard to pick the right revision within that branch. if library is/was doing CI, try to get revision which passed CI. otherwise, if library provides a test suite, try to choose revision which passes test suite. otherwise, try to manually check some typical scenario to ensure at least basic level of stability. - some libraries (especially ancient, public domain) aren't hosted in source control, they don't appear to have any history, just provided as-is somewhere. in that case, try to check if there is a date or version in header file. try to find out the date code was published. if nothing was found, just get today's date with cci. prefix.
Originally posted by @SSE4 in #2437 (comment)
uilianries