<commit_before>#ifndef VERSION_HPP_
#define VERSION_HPP_

// An enumeration of the current and previous recognized versions.  Every
// serialization / deserialization happens relative to one of these versions.
enum class cluster_version_t {
    // The versions are _currently_ contiguously numbered.  If this becomes untrue,
    // be sure to carefully replace the ARCHIVE_PRIM_MAKE_RANGED_SERIALIZABLE line
    // that implements serialization.
    v1_13 = 0,

    // This is used in places where _something_ needs to change when a new cluster
    // version is created.  (Template instantiations, switches on version number,
    // etc.)
    v1_13_is_latest = v1_13,

    LATEST = v1_13,

    // This exists as long as the clustering code only supports the use of one
    // version.  It uses cluster_version_t::CLUSTER wherever it uses this.  (LATEST
    // is correct wherever it seems like it's *always* going to be appropriate for
    // the code to use the latest version.
    CLUSTER = LATEST,

    // TODO: Remove ONLY_VERSION entirely.
    // ONLY_VERSION should only exist as long as there's only one version.  A few
    // assertions check it -- that code should be fixed to explicitly handle multiple
    // versions, but we're procrastinating that for now.
    ONLY_VERSION = v1_13_is_latest,
};

// We will not (barring a bug) even attempt to deserialize a version number that we
// do not support.  Cluster nodes connecting to us make sure that they are
// communicating with a version number that we also support (the max of our two
// versions) and we don't end up deserializing version numbers in that situation
// anyway (yet).  Files on disk will not (barring corruption, or a bug) cause us to
// try to use a version number that we do not support -- we'll see manually whether
// we can read the serializer file by looking at the disk_format_version field in the
// metablock.
//
// At some point the set of cluster versions and disk versions that we support might
// diverge.  It's likely that we'd support a larger window of serialization versions
// in the on-disk format.
//
// Also, note: it's possible that versions will not be linearly ordered: Suppose we
// release v1.17 and then v1.18.  Perhaps v1.17 supports v1_16 and v1_17 and v1.18
// supports v1_17 and v1_18.  Suppose we then need to make a point-release, v1.17.1,
// that changes a serialization format, and we add a new cluster version v1_17_1.
// Then, v1.18 would still only support v1_17 and v1_18.  However, v1.18.1 might
// support v1_17, v1_17_1, and v1_18 (and v1_18_1 if that needs to be created).

#endif  // VERSION_HPP_<commit_msg>Removed the unused value cluster_version_t::ONLY_VERSION.<commit_after>#ifndef VERSION_HPP_
#define VERSION_HPP_

// An enumeration of the current and previous recognized versions.  Every
// serialization / deserialization happens relative to one of these versions.
enum class cluster_version_t {
    // The versions are _currently_ contiguously numbered.  If this becomes untrue,
    // be sure to carefully replace the ARCHIVE_PRIM_MAKE_RANGED_SERIALIZABLE line
    // that implements serialization.
    v1_13 = 0,

    // This is used in places where _something_ needs to change when a new cluster
    // version is created.  (Template instantiations, switches on version number,
    // etc.)
    v1_13_is_latest = v1_13,

    LATEST = v1_13,

    // This exists as long as the clustering code only supports the use of one
    // version.  It uses cluster_version_t::CLUSTER wherever it uses this.  (LATEST
    // is correct wherever it seems like it's *always* going to be appropriate for
    // the code to use the latest version.
    CLUSTER = LATEST,
};

// We will not (barring a bug) even attempt to deserialize a version number that we
// do not support.  Cluster nodes connecting to us make sure that they are
// communicating with a version number that we also support (the max of our two
// versions) and we don't end up deserializing version numbers in that situation
// anyway (yet).  Files on disk will not (barring corruption, or a bug) cause us to
// try to use a version number that we do not support -- we'll see manually whether
// we can read the serializer file by looking at the disk_format_version field in the
// metablock.
//
// At some point the set of cluster versions and disk versions that we support might
// diverge.  It's likely that we'd support a larger window of serialization versions
// in the on-disk format.
//
// Also, note: it's possible that versions will not be linearly ordered: Suppose we
// release v1.17 and then v1.18.  Perhaps v1.17 supports v1_16 and v1_17 and v1.18
// supports v1_17 and v1_18.  Suppose we then need to make a point-release, v1.17.1,
// that changes a serialization format, and we add a new cluster version v1_17_1.
// Then, v1.18 would still only support v1_17 and v1_18.  However, v1.18.1 might
// support v1_17, v1_17_1, and v1_18 (and v1_18_1 if that needs to be created).

#endif  // VERSION_HPP_
{'fraction_non_alphanumeric': 0.06476114331401159, 'fraction_numerical': 0.02938237057765341, 'mean_word_length': 3.2879177377892033, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4391300', 'n_tokens_mistral': 1523, 'n_tokens_neox': 1424, 'n_words': 703}