Difference between revisions of "Versioning"

From ETSI Forge
Jump to: navigation, search
(Created page with "<big>To ensure that permanent URLs to an attachment for a specification is readable and permanent follow the best practices listed below. == Use Tags == == Pretty view vs Ra...")
 
Line 1: Line 1:
 
<big>To ensure that permanent URLs to an attachment for a specification is readable and permanent follow the best practices listed below.
 
<big>To ensure that permanent URLs to an attachment for a specification is readable and permanent follow the best practices listed below.
 
+
</big>
 
== Use Tags ==
 
== Use Tags ==
  
Line 30: Line 30:
 
     TB_XYZ_ASN.1_modules_v4
 
     TB_XYZ_ASN.1_modules_v4
 
     etc.
 
     etc.
 
</big>
 

Revision as of 03:29, 22 February 2019

To ensure that permanent URLs to an attachment for a specification is readable and permanent follow the best practices listed below.

Use Tags

Pretty view vs Raw view

Once the final version of the file is uploaded to the repository (see here how to do it), you want to create a GIT Tag with the correct version (e.g. the version of the ETSI Deliverable).

To do so, follow the steps:

  1. Go to the repository
  2. In the menu on the left, select Repository->Tags

Do not encode versioning in the files

Do not hard code the version in the file name, e.g. DO NOT:

   my_file_v2.1.1.json

instead use

   my_file.json

and let the GIT system manage and provide the licensing information.

In the same way, it is very bad practice to keep a list of folders such as (example based on fictitious ASN.1 modules for TB XYZ):

   TB_XYZ_ASN.1_modules_v1
   TB_XYZ_ASN.1_modules_v2
   TB_XYZ_ASN.1_modules_v3
   TB_XYZ_ASN.1_modules_v4
   etc.