Δοθέντος ενός αριθμού έκδοσης ΚΥΡΙΑ.ΔΕΥΤΕΡΕΥΟΥΣΑ.ΔΙΟΡΘΩΣΗ (MAJOR.MINOR.PATCH), αυξήστε την:
Πρόσθετες ετικέτες για μεταδεδομένα προ-κυκλοφορίας και χτισίματος, είναι διαθέσιμες ως επεκτάσειςστη μορφή ΚΥΡΙΑ.ΔΕΥΤΕΡΕΥΟΥΣΑ.ΔΙΟΡΘΩΣΗ.
Στον κόσμο της διαχείρισης λογισμικού υπάρχει ένα διαβόητο μέρος που ονομάζεται «κόλαση εξαρτήσεων». Όσο περισσότερο μεγαλώνει το σύστημά σας και όσο περισσότεραπακέτα ενσωματώνετε στο λογισμικό σας, τόσο πιο πιθανό είναι να βρεθείτε μια μέρασε απόγνωση.
Σε συστήματα με πολλές εξαρτήσεις, η κυκλοφορία νέων εκδόσεων πακέτων μπορεί να γίνει πολύ γρήγορα ένας εφιάλτης. Αν οι προδιαγραφές της εξάρτησης είναι πολύ αυστηρές, είστεσε κίνδυνο κλειδώματος έκδοσης (σε αδυναμία αναβάθμισης ενός πακέτου χωρίς να πρέπει νακυκλοφορήσουν νέες εκδόσεις από κάθε εξαρτώμενο πακέτο). Αν οι εξαρτήσεις ορίζονται πολύχαλαρά, αναπόφευκτα θα επηρεαστείτε από την αναμικτικότητα έκδοσης (υποθέτοντας συμβατότητα με περισσότερες μελλοντικές εκδόσεις απ’ ότι είναι λογικό). Η κόλαση εξαρτήσεων είναι εκείπου το κλείδωμα έκδοσης ή/και η αναμικτικότητα έκδοσης, σας αποτρέπουν από το να προωθήσετεεύκολα και με ασφάλεια το έργο σας.
Ως μια λύση σ’ αυτό το πρόβλημα, προτείνουμε ένα απλό σετ κανόνων καιαπαιτήσεων που υπαγορεύουν το πως οι αριθμοί εκδόσεων καθορίζονται και αυξάνονται.Αυτοί οι κανόνες βασίζονται, αλλά δεν περιορίζονται απαραίτητα, σε προϋπάρχουσεςδιαδεδομένες κοινές πρακτικές σε χρήση τόσο σε κλειστό όσο και σε λογισμικόανοιχτού κώδικα. Για να λειτουργήσει αυτό το σύστημα, πρώτα πρέπει να δηλώσετεένα δημόσιο API. Αυτό μπορεί να αποτελείται από τεκμηρίωση ή να επιβάλλεται απότον ίδιο τον κώδικα. Όπως και να ‘χει είναι σημαντικό αυτό το API να είναιξεκάθαρο και συγκεκριμένο. Μόλις ταυτοποιήσετε το δημόσιο API, κοινοποιείτε τιςαλλαγές σ’ αυτό με συγκεκριμένες αυξήσεις στον αριθμό έκδοσης. Σκεφτείτε μίαέκδοση της μορφής X.Y.Z (Κύρια.Δευτερεύουσα.Διόρθωση). Διορθώσεις σφαλμάτων πουδεν επηρεάζουν το API αυξάνουν την έκδοση διόρθωσης, προσθήκες/αλλαγές στο APIοι οποίες είναι συμβατές προς τα πίσω αυξάνουν τη δευτερεύουσα έκδοση, και αλλαγές ασύμβατες με το API αυξάνουν την κύρια έκδοση.
Ονομάζουμε αυτό το σύστημα «Σημασιολογική δημιουργία εκδόσεων».Με αυτό το σχήμα, οι αριθμοί εκδόσεων και ο τρόπος που αλλάζουν, εκφράζουνκάποιο νόημα σχετικά με τον υποκείμενο κώδικα και το τι έχει τροποποιηθείαπό τη μία έκδοση στην επόμενη.
Οι λέξεις κλειδιά «ΠΡΕΠΕΙ» (MUST), «ΔΕΝ ΠΡΕΠΕΙ» (MUST NOT), «ΑΠΑΙΤΕΙΤΑΙ» (REQUIRED),«ΠΡΕΠΕΙ» (SHALL), «ΔΕΝ ΠΡΕΠΕΙ» (SHALL NOT), «ΣΥΝΙΣΤΆΤΑΙ» (SHOULD), «ΔΕ ΣΥΝΙΣΤΆΤΑΙ»(SHOULD NOT), «ΣΥΝΙΣΤΆΤΑΙ» (RECOMMENDED), «ΜΠΟΡΕΙ» (MAY), και «ΠΡΟΑΙΡΕΤΙΚΑ» (OPTIONAL)σε αυτό το έγγραφο, πρέπει να ερμηνεύονται όπως περιγράφεται στοRFC 2119.
Λογισμικό που χρησιμοποιεί Σημασιολογική δημιουργία εκδόσεων ΠΡΕΠΕΙ να δηλώνειένα δημόσιο API. Αυτό το API μπορεί να δηλωθεί στον ίδιο τον κώδικα του ή να υπάρχειαποκλειστικά στην τεκμηρίωση. Όπως και αν γίνει, ΣΥΝΙΣΤΆΤΑΙ να είναι ακριβές καιεμπεριστατωμένο.
Ένας φυσιολογικός αριθμός έκδοσης ΠΡΕΠΕΙ να έχει τη μορφή X.Y.Z όπου X, Y, και Zείναι μη-αρνητικοί ακέραιοι, που ΔΕΝ ΠΡΕΠΕΙ να περιέχουν προπορευόμενα μηδενικά.Το Χ είναι η κύρια έκδοση, το Υ είναι η δευτερεύουσα έκδοση, και το Ζ είναι ηέκδοση διόρθωσης. Κάθε στοιχείο ΠΡΕΠΕΙ να αυξάνεται αριθμητικά.Για παράδειγμα: 1.9.0 -> 1.10.0 -> 1.11.0.
Μόλις ένα πακέτο με έκδοση κυκλοφορήσει, τα περιεχόμενα αυτής της έκδοσηςΔΕΝ ΠΡΕΠΕΙ να τροποποιηθούν. Κάθε τροποποίηση ΠΡΕΠΕΙ να κυκλοφορεί με νέα έκδοση.
Ο αριθμός κύριας έκδοσης μηδέν (0.y.z) είναι για την αρχική ανάπτυξη.Οτιδήποτε ΜΠΟΡΕΙ να αλλάξει οποιαδήποτε στιγμή. Το δημόσιο API ΔΕ ΣΥΝΙΣΤΆΤΑΙνα θεωρείται σταθερό.
Η έκδοση 1.0.0 ορίζει το δημόσιο API. Ο τρόπος με τον οποίο ο αριθμός έκδοσηςαυξάνεται μετά από κάθε κυκλοφορία, εξαρτάται από αυτό το δημόσιο API και τοπως αλλάζει.
Η Διορθωτική έκδοση Z (x.y.Z | x > 0) ΠΡΕΠΕΙ να αυξάνεται μόνο αν εισάγονταιδιορθώσεις σφαλμάτων συμβατές προς τα πίσω. Μία διόρθωση σφάλματος ορίζεταιως μια εσωτερική αλλαγή που διορθώνει μια εσφαλμένη συμπεριφορά.
Η Δευτερεύουσα έκδοση Y (x.Y.z | x > 0) ΠΡΕΠΕΙ να αυξάνεται αν μια νέα,συμβατή προς τα πίσω, λειτουργικότητα, εισάγεται στο δημόσιο API. ΠΡΕΠΕΙ νααυξάνεται αν κάποια λειτουργικότητα, οποιουδήποτε δημόσιου API, χαρακτηρίζεταιως καταργημένη. ΜΠΟΡΕΙ να αυξηθεί αν σημαντική νέα λειτουργικότητα ή βελτιώσειςεισάγονται μαζί με τον ιδιωτικό κώδικα. ΜΠΟΡΕΙ να περιλαμβάνει αλλαγές επιπέδουδιόρθωσης. Η έκδοση διόρθωσης ΠΡΕΠΕΙ να επανέλθει στο 0 όταν μία δευτερεύουσαέκδοση αυξάνεται.
Η Κύρια έκδοση X (X.y.z | X > 0) ΠΡΕΠΕΙ να αυξάνεται αν εισάγονται στο δημόσιοAPI οποιεσδήποτε αλλαγές που είναι ασύμβατες προς τα πίσω. ΜΠΟΡΕΙ επίσης νασυμπεριλαμβάνει δευτερεύουσες και διορθωτικές αλλαγές. Οι διορθωτικές και οιδευτερεύουσες εκδόσεις ΠΡΕΠΕΙ να επανέρχονται στο 0 όταν η κύρια έκδοση αυξάνεται.
Μια έκδοση προ-κυκλοφορίας ΜΠΟΡΕΙ να επισημαίνεται επισυνάπτοντας μία παύλακαι μία σειρά από αναγνωριστικά διαχωρισμένα με τελεία, αμέσως μετά την έκδοσηδιόρθωσης. Τα αναγνωριστικά ΠΡΕΠΕΙ να αποτελούνται μόνο από αλφαριθμητικούςχαρακτήρες ASCII και παύλες [0-9A-Za-z-]. Τα αναγνωριστικά ΔΕΝ ΠΡΕΠΕΙ να είναικενά. Τα αριθμητικά αναγνωριστικά ΔΕΝ ΠΡΕΠΕΙ να περιλαμβάνουν προπορευόμεναμηδενικά. Οι εκδόσεις προ-κυκλοφορίας έχουν χαμηλότερη προτεραιότητα απότη συσχετιζόμενη φυσιολογική έκδοση. Μία έκδοση προ-κυκλοφορίας υποδεικνύειότι η έκδοση είναι ασταθής και μπορεί να μην ικανοποιεί τις επιθυμητές απαιτήσειςσυμβατότητας όπως επισημαίνεται από τη συσχετιζόμενη φυσιολογική έκδοση.Παραδείγματα: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7,1.0.0-x.7.z.92, 1.0.0-x-y-z.--.
Μεταδεδομένα χτισίματος ΜΠΟΡΕΙ να επισημαίνονται επισυνάπτοντας το σύμβολοτης πρόσθεσης και μία σειρά από αναγνωριστικά διαχωρισμένα με τελεία, αμέσωςμετά τη διόρθωση ή την έκδοση προ-κυκλοφορίας. Τα αναγνωριστικά ΠΡΕΠΕΙ νααποτελούνται μόνο από αλφαριθμητικούς χαρακτήρες ASCII και παύλες [0-9A-Za-z-].Τα αναγνωριστικά ΔΕΝ ΠΡΕΠΕΙ να είναι κενά. Τα μεταδεδομένα χτισίματος ΠΡΕΠΕΙ νααγνοούνται όταν αποφασίζεται η προτεραιότητα έκδοσης. Συνεπώς, όταν δύοεκδόσεις διαφέρουν μόνο στα μεταδεδομένα χτισίματος, τότε έχουν την ίδιαπροτεραιότητα. Παραδείγματα: 1.0.0-alpha+001, 1.0.0+20130313144700,1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3----117B344092BD.
Ως προτεραιότητα αναφέρεται το πως δύο εκδόσεις συγκρίνονται μεταξύ τουςόταν ταξινομούνται.
Η προτεραιότητα ΠΡΕΠΕΙ να υπολογίζεται διαχωρίζοντας την έκδοση σταεπιμέρους κύρια, δευτερεύοντα, διορθωτικά και προ-κυκλοφορίαςαναγνωριστικά, με αυτή τη σειρά (Τα μεταδεδομένα χτισίματος δε λαμβάνονται υπόψη στην προτεραιότητα).
Η προτεραιότητα αποφασίζεται από την πρώτη διαφορά όταν συγκρίνεται τοκαθένα από αυτά τα αναγνωριστικά, από αριστερά προς τα δεξιά ως εξής:Κύριες, δευτερεύουσες, και διορθωτικές εκδόσεις συγκρίνονται πάντααριθμητικά.
Παράδειγμα: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1.
Όταν κύρια, δευτερεύουσα και διορθωτική είναι ίσα, η έκδοση προ-κυκλοφορίας έχει χαμηλότερη προτεραιότητα από μία φυσιολογική έκδοση:
Παράδειγμα: 1.0.0-alpha < 1.0.0.
Η προτεραιότητα για δύο εκδόσεις προ-κυκλοφορίας, με ίδια κύρια, δευτερεύουσα, και διορθωτική έκδοση, ΠΡΕΠΕΙ να αποφασίζεται συγκρίνονταςκάθε αναγνωριστικό διαχωρισμένο με τελεία, από αριστερά προς δεξιά,μέχρι να βρεθεί διαφορά ως εξής:
Αναγνωριστικά που αποτελούνται μόνο από ψηφία συγκρίνονται αριθμητικά.
Αναγνωριστικά με γράμματα ή παύλες συγκρίνονται λεξιλογικά μεσειρά ταξινόμησης ASCII.
Τα αριθμητικά αναγνωριστικά πάντα έχουν χαμηλότερη προτεραιότητααπό τα μη-αριθμητικά αναγνωριστικά.
Ένα μεγαλύτερο σετ από πεδία προ-κυκλοφορίας έχει υψηλότερηπροτεραιότητα από ένα μικρότερο σετ, αν όλα τα προηγούμενααναγνωριστικά είναι ίσα.
Παράδειγμα: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-alpha.beta < 1.0.0-beta < 1.0.0-beta.2 < 1.0.0-beta.11 < 1.0.0-rc.1 < 1.0.0.
<valid semver> ::= <version core> | <version core> "-" <pre-release> | <version core> "+" <build> | <version core> "-" <pre-release> "+" <build><version core> ::= <major> "." <minor> "." <patch><major> ::= <numeric identifier><minor> ::= <numeric identifier><patch> ::= <numeric identifier><pre-release> ::= <dot-separated pre-release identifiers><dot-separated pre-release identifiers> ::= <pre-release identifier> | <pre-release identifier> "." <dot-separated pre-release identifiers><build> ::= <dot-separated build identifiers><dot-separated build identifiers> ::= <build identifier> | <build identifier> "." <dot-separated build identifiers><pre-release identifier> ::= <alphanumeric identifier> | <numeric identifier><build identifier> ::= <alphanumeric identifier> | <digits><alphanumeric identifier> ::= <non-digit> | <non-digit> <identifier characters> | <identifier characters> <non-digit> | <identifier characters> <non-digit> <identifier characters><numeric identifier> ::= "0" | <positive digit> | <positive digit> <digits><identifier characters> ::= <identifier character> | <identifier character> <identifier characters><identifier character> ::= <digit> | <non-digit><non-digit> ::= <letter> | "-"<digits> ::= <digit> | <digit> <digits><digit> ::= "0" | <positive digit><positive digit> ::= "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"<letter> ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" | "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"Αυτή δεν είναι μια νέα ή επαναστατική ιδέα. Στην πραγματικότητα, πιθανά ήδηκάνετε κάτι κοντινό σ’ αυτό. Το πρόβλημα είναι ότι το «κοντινό» δεν είναι αρκετά καλό. Χωρίς συμμόρφωση σε κάποια μορφή επίσημης προδιαγραφής, οιαριθμοί εκδόσεων είναι ουσιαστικά ανώφελοι στη διαχείριση εξαρτήσεων.Δίνοντας ένα όνομα και ξεκάθαρη ερμηνεία στις παραπάνω ιδέες, γίνεται εύκολονα κοινοποιήσετε τις προθέσεις σας στους χρήστες του λογισμικού σας.Μόλις αυτές οι προθέσεις ξεκαθαριστούν, μπορούν τελικά να κατασκευαστούνευέλικτες (αλλά όχι πολύ ευέλικτες) προδιαγραφές εξαρτήσεων.
Ένα απλό παράδειγμα θα επιδείξει πως η Σημασιολογική Δημιουργία Εκδόσεωνμπορεί να κάνει την κόλαση εξαρτήσεων παρελθόν.Σκεφτείτε μια βιβλιοθήκη που ονομάζεται «Πυροσβεστικό». Αυτή χρειάζεταιένα πακέτο που χρησιμοποιεί Σημασιολογική Δημιουργία Εκδόσεων και ονομάζεται«Σκάλα». Κατά τη χρονική στιγμή που το Πυροσβεστικό δημιουργείται, η Σκάλαείναι στην έκδοση 3.1.0. Επειδή το Πυροσβεστικό χρησιμοποιεί κάποια λειτουργικότητα που πρωτοεισάχθηκε στην 3.1.0, μπορείτε με ασφάλεια ναορίσετε την εξάρτηση από την Σκάλα ως μεγαλύτερη ή ίση με 3.1.0, αλλάμικρότερη από 4.0.0. Τώρα, όταν γίνει διαθέσιμη η έκδοση 3.1.1 και 3.2.0της Σκάλας, μπορείτε να τις κυκλοφορήσετε στο δικό σας σύστημα διαχείρισηςπακέτων, και να γνωρίζετε ότι θα είναι συμβατές με το υπάρχον εξαρτημένολογισμικό.
Ως ένας υπεύθυνος προγραμματιστής, φυσικά θα θέλετε να επαληθεύσετε ότιοποιεσδήποτε αναβαθμίσεις πακέτων, λειτουργούν όπως διαφημίζονται.Ο πραγματικός κόσμος είναι ένα ακατάστατο μέρος και δεν μπορούμε να κάνουμετίποτα άλλο εκτός από το να είμαστε σε εγρήγορση. Αυτό που μπορείτε νακάνετε είναι να επιτρέψετε στη Σημασιολογική Δημιουργία Εκδόσεων νασας παρέχει έναν λογικό τρόπο να κυκλοφορείτε και να αναβαθμίζετε πακέταχωρίς να πρέπει να κυκλοφορείτε νέες εκδόσεις για τα εξαρτημένα πακέτα,εξοικονομώντας έτσι χρόνο και ταλαιπωρία.
Αν όλα αυτά ακούγονται επιθυμητά, όλα όσα πρέπει να κάνετε για να αρχίσετενα χρησιμοποιείτε τη Σημασιολογική Δημιουργία Εκδόσεων, είναι να δηλώσετεότι πρόκειται να το κάνετε και να ακολουθήσετε τους κανόνες. Δημιουργήστε ένασύνδεσμο από το README προς αυτό τον ιστότοπο, ώστε οι άλλοι να γνωρίζουντους κανόνες και να μπορούν να επωφεληθούν από αυτούς.
Το απλούστερο πράγμα που μπορείτε να κάνετε, είναι να ξεκινήσετε την αρχικήσας κυκλοφορία ανάπτυξης στο 0.1.0 και μετά να αυξάνετε τη δευτερεύουσαέκδοση με κάθε επακόλουθη κυκλοφορία.
Αν το λογισμικό σας χρησιμοποιείται στην παραγωγή, πιθανά πρέπει ήδη ναείναι 1.0.0. Αν έχετε ένα σταθερό API στο οποίο οι χρήστες βασίζονται,πρέπει να είναι 1.0.0. Αν ανησυχείτε πολύ σχετικά με τη συμβατότηταπρος τα πίσω, πιθανά πρέπει ήδη να είναι 1.0.0.
Η κύρια έκδοση μηδέν είναι για την ταχεία ανάπτυξη. Αν αλλάζετε το APIκάθε μέρα, είτε παραμείνετε στην έκδοση 0.y.z, είτε μεταβείτε σε έναδιαφορετικό κλάδο ανάπτυξης, καθώς εργάζεστε για την επόμενη κύρια έκδοση.
Αυτή είναι μια ερώτηση υπεύθυνης ανάπτυξης και προνοητικότητας. Ασύμβατεςαλλαγές δε θα πρέπει να εισάγονται εύκολα σε λογισμικό που έχει πολύεξαρτώμενο κώδικα. Το κόστος που πρέπει να πραγματοποιηθεί για την αναβάθμισημπορεί να είναι σημαντικό. Το να χρειάζεται να προσαρμόσετε τις κύριες εκδόσειςγια να κυκλοφορήσετε μη συμβατές αλλαγές σημαίνει ότι θα σκεφτείτε τον αντίκτυποτων αλλαγών σας και θα αξιολογήσετε την αναλογία κόστους/οφέλους.
Είναι δική σας ευθύνη ως επαγγελματίας προγραμματιστής να τεκμηριώσετε σωστάτο λογισμικό που προορίζεται για χρήση από άλλους. Η διαχείριση της πολυπλοκότηταςτου λογισμικού είναι ένα εξαιρετικά σημαντικό μέρος για τη διατήρηση τηςαποτελεσματικότητας ενός εγχειρήματος και αυτό είναι δύσκολο να γίνει εάν κανείςδεν ξέρει πώς να χρησιμοποιεί το λογισμικό σας ή ποιες μεθόδους είναι ασφαλείς νακαλέσει. Μακροπρόθεσμα, η Σημασιολογική Δημιουργία Εκδόσεων και η επιμονή σε ένακαλά καθορισμένο δημόσιο API μπορούν να διατηρήσουν όλους και όλα σε ομαλή λειτουργία.
Μόλις συνειδητοποιήσετε ότι έχετε παραβιάσει την προδιαγραφή της ΣημασιολογικήςΔημιουργίας Εκδόσεων, διορθώστε το πρόβλημα και κυκλοφορήστε μια νέα δευτερεύουσαέκδοση που διορθώνει το πρόβλημα και αποκαθιστά τη συμβατότητα προς τα πίσω.Ακόμη και υπό αυτές τις συνθήκες, είναι απαράδεκτη η τροποποίηση των κυκλοφορημένωνεκδόσεων. Εάν είναι κατάλληλο, τεκμηριώστε την ανάρμοστη έκδοση και ενημερώστετους χρήστες σας για το πρόβλημα, ώστε να γνωρίζουν ποια είναι η ανάρμοστη έκδοση.
Αυτό θα θεωρηθεί συμβατό, καθώς δεν επηρεάζει το δημόσιο API. Το λογισμικόπου εξαρτάται ρητά από τις ίδιες εξαρτήσεις με το πακέτο σας θα πρέπει να έχειτις δικές του προδιαγραφές εξάρτησης και ο συγγραφέας θα παρατηρήσει τυχόνδιενέξεις. Ο προσδιορισμός εάν η αλλαγή είναι επίπεδο διόρθωσης ή δευτερεύουσας τροποποίησης, εξαρτάται από το αν ενημερώσατε τις εξαρτήσεις σαςγια να διορθώσετε ένα σφάλμα ή να εισαγάγετε νέα λειτουργικότητα. Συνήθως θαπεριμέναμε πρόσθετο κώδικα για την τελευταία περίπτωση, η οποία προφανώς είναι μια αύξηση δευτερεύοντος επιπέδου.
Χρησιμοποιήστε την καλύτερη κρίση σας. Εάν έχετε τεράστιο κοινό που θα επηρεαστείδραστικά με την αλλαγή της συμπεριφοράς, πίσω σε αυτό που προόριζε το δημόσιο API,τότε ίσως είναι καλύτερο να εκτελέσετε μια κυκλοφορία κύριας έκδοσης, παρόλο πουη επισκευή θα μπορούσε να θεωρηθεί αυστηρά ως διορθωτική κυκλοφορία. Θυμηθείτε,η Σημασιολογική Δημιουργία Εκδόσεων έχει να κάνει με τη μετάδοση νοήματος με τοντρόπο που αλλάζει ο αριθμός έκδοσης. Εάν αυτές οι αλλαγές είναι σημαντικές γιατους χρήστες σας, χρησιμοποιήστε τον αριθμό έκδοσης για να τους ενημερώσετε.
Η κατάργηση υπάρχουσας λειτουργικότητας είναι φυσιολογικό μέρος της ανάπτυξηςλογισμικού και συχνά απαιτείται για να σημειωθεί πρόοδος. Όταν καταργείτε μέροςτου δημόσιου API σας, θα πρέπει να κάνετε δύο πράγματα: (1) να ενημερώσετε τηντεκμηρίωσή για να μάθουν οι χρήστες σχετικά με την αλλαγή, (2) να εκδώσετε μιανέα δευτερεύουσα κυκλοφορία με την κατάργηση. Προτού αφαιρέσετε εντελώς τηλειτουργικότητα σε μια νέα κύρια κυκλοφορία, θα πρέπει να υπάρχει τουλάχιστονμία δευτερεύουσα κυκλοφορία που να περιέχει την κατάργηση, ώστε οι χρήστες ναμπορούν να μεταβούν ομαλά στο νέο API.
Όχι, αλλά χρησιμοποιήστε καλή κρίση. Μια συμβολοσειρά έκδοσης 255 χαρακτήρωνγια παράδειγμα, είναι πιθανώς υπερβολική. Επίσης, συγκεκριμένα συστήματα μπορείνα επιβάλλουν τα δικά τους όρια στο μέγεθος της συμβολοσειράς.
Όχι, το «v1.2.3» δεν είναι σημασιολογική έκδοση. Ωστόσο, το πρόθεμα μιαςσημασιολογικής έκδοσης με ένα «v», είναι ένας συνηθισμένος τρόπος (στα Αγγλικά)για να δηλωθεί ότι είναι αριθμός έκδοσης. Η συντομογραφία του «version» ως «v»εμφανίζεται συχνά με τον έλεγχο εκδόσεων. Παράδειγμα:git tag v1.2.3 -m "Έκδοση κυκλοφορίας 1.2.3", στην περίπτωση αυτή το «v1.2.3»είναι το όνομα μιας ετικέτας και η σημασιολογική έκδοση είναι «1.2.3».
Υπάρχουν δύο. Μία με ονοματισμένες ομάδες, named groups, για εκείνα τα συστήματαπου τα υποστηρίζουν (PCRE [Perl Compatible Regular Expressions, δηλ. Perl, PHP και R], Python και Go).
Δείτε:https://regex101.com/r/Ly7O1x/3/
^(?P<major>0|[1-9]\d*)\.(?P<minor>0|[1-9]\d*)\.(?P<patch>0|[1-9]\d*)(?:-(?P<prerelease>(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P<buildmetadata>[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$Και μία με αριθμημένες ομάδες σύληψης, capture groups, (έτσι cg1 = κύρια,cg2 = δευτερεύουσα, cg3 = διορθωτική, cg4 = προκυκλοφορία και cg5 = μεταδεδομέναχτισίματος) που είναι συμβατή με ECMA Script (JavaScript),PCRE (Perl Compatible Regular Expressions, δηλαδή Perl, PHP και R), Python και Go.
Δείτε:https://regex101.com/r/vkijKf/1/
^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$Η προδιαγραφή Σημασιολογικής Δημιουργίας Εκδόσεων συγγράφηκε αρχικά απότονTom Preston-Werner, δημιουργό του Gravatarκαι συνιδρυτή του GitHub.
Την αρχική μετάφραση στα Ελληνικά έκανε οΕυάγγελος Σκαρμούτσος
Αν θέλετε να αφήσετε τα σχόλιά σας, παρακαλώανοίξτε ένα issue στοGitHub.