Changelog
Νέες λειτουργίες, βελτιώσεις, διορθώσεις, security updates, breaking changes και απαιτούμενες ενέργειες ανά έκδοση του Nutrition Hub.
Εμφανίζονται όλες οι καταχωρίσεις.
Τρέχουσα δημόσια κατάσταση
Σε ανάπτυξη / πριν από την επόμενη έκδοση
Η ενότητα “Unreleased” χρησιμοποιείται μόνο για αλλαγές που έχουν επιβεβαιωθεί και πρόκειται να συμπεριληφθούν στην επόμενη έκδοση. Δεν πρέπει να περιέχει υποσχέσεις χωρίς εγκεκριμένο scope.
Προσθέστε πραγματικές καταχωρίσεις όταν η έκδοση περάσει development review και release freeze.
Το changelog πρέπει να προκύπτει από tags, release notes, verified commits και το πραγματικό deployment history.
Πώς οργανώνεται κάθε έκδοση
Αριθμός έκδοσης
Για παράδειγμα 1.4.2, σύμφωνα με την εγκεκριμένη
πολιτική versioning.
Ημερομηνία κυκλοφορίας
Η πραγματική ημερομηνία κατά την οποία η έκδοση έγινε διαθέσιμη σε production.
Απαιτήσεις
WordPress, PHP, schema, migrations ή άλλες αλλαγές συμβατότητας.
Required actions
Backup, migration, reconnect, cache clear ή άλλη ενέργεια πριν ή μετά το update.
Ιστορικό εκδόσεων
Αλλάξτε φίλτρο ή όρο αναζήτησης.
Τίτλος πραγματικής έκδοσης
Ημερομηνία: YYYY-MM-DD
Αντιγράψτε το μόνο όταν υπάρχουν επιβεβαιωμένα release notes και αφαιρέστε την ένδειξη Template.
Added Νέες λειτουργίες
- Προσθέστε συγκεκριμένη λειτουργία και το όφελος για τον χρήστη.
Improved Βελτιώσεις
- Προσθέστε πραγματική βελτίωση απόδοσης, UX ή αξιοπιστίας.
Fixed Διορθώσεις
- Περιγράψτε το πρόβλημα χωρίς έκθεση προσωπικών δεδομένων.
Security Security updates
- Δημοσιεύστε ασφαλή περίληψη μετά τη διάθεση της διόρθωσης.
Breaking Breaking changes
- Αναφέρετε αλλαγές που απαιτούν migration ή configuration update.
- Πάρτε πλήρες backup πριν από την αναβάθμιση.
- Δοκιμάστε την έκδοση σε staging.
- Προσθέστε μόνο τις πραγματικές ειδικές ενέργειες της έκδοσης.
Αν δεν υπάρχει αξιόπιστο παλαιότερο release history, ξεκινήστε από την πρώτη επίσημη production έκδοση. Μην ανακατασκευάζετε παλιές εκδόσεις από μνήμη.
Τι σημαίνει κάθε κατηγορία
| Κατηγορία | Χρήση | Παράδειγμα |
|---|---|---|
| Added | Νέα λειτουργία ή νέο integration. | Νέο report ή νέα δυνατότητα portal. |
| Improved | Βελτίωση υπάρχουσας λειτουργίας. | Ταχύτερο loading ή καθαρότερο workflow. |
| Fixed | Διόρθωση bug ή λανθασμένης συμπεριφοράς. | Διόρθωση διπλής ειδοποίησης. |
| Security | Hardening ή security correction. | Ενίσχυση authorization ή token handling. |
| Breaking | Αλλαγή που απαιτεί προσαρμογή. | Νέο minimum PHP ή αλλαγή API contract. |
| Deprecated | Λειτουργία που θα αφαιρεθεί σε επόμενη έκδοση. | Παλιό endpoint με ανακοινωμένη ημερομηνία λήξης. |
Semantic versioning
Breaking αλλαγές ή μεγάλη νέα γενιά.
Νέες backward-compatible λειτουργίες.
Backward-compatible fixes και μικρές βελτιώσεις.
Αν η ανάπτυξη χρησιμοποιεί διαφορετικό μοντέλο, η δημόσια περιγραφή πρέπει να προσαρμοστεί στο πραγματικό release process.
Πώς δημοσιεύονται security fixes
Επιβεβαίωση και περιορισμός
Η πιθανή ευπάθεια αξιολογείται ιδιωτικά και περιορίζεται η πρόσβαση στις τεχνικές λεπτομέρειες.
Διόρθωση και tests
Προστίθεται fix, regression test και έλεγχος σχετικών modules.
Διάθεση ενημέρωσης
Η ασφαλής έκδοση γίνεται διαθέσιμη πριν ή μαζί με τη δημόσια ανακοίνωση.
Δημόσια περίληψη
Το changelog περιγράφει impact και required action χωρίς exploit details που αυξάνουν τον κίνδυνο.
Πριν από κάθε αναβάθμιση
Πριν δημοσιευτεί ένα release note
- Το version tag υπάρχει και αντιστοιχεί στο production package.
- Η ημερομηνία είναι η πραγματική ημερομηνία κυκλοφορίας.
- Οι αλλαγές έχουν περάσει QA ή release acceptance.
- Τα database migrations αναφέρονται με σαφήνεια.
- Τα breaking changes έχουν migration instructions.
- Οι security διορθώσεις δεν αποκαλύπτουν μη επιδιορθωμένο exploit.
- Δεν εμφανίζονται customer names, patient data ή internal secrets.
- Έχουν ενημερωθεί docs, error codes και system requirements όπου χρειάζεται.
Συχνές ερωτήσεις
Πρέπει να εμφανίζονται όλες οι εσωτερικές αλλαγές;
Όχι. Το δημόσιο changelog περιλαμβάνει αλλαγές που επηρεάζουν λειτουργία, ασφάλεια, συμβατότητα ή εμπειρία χρήστη. Εσωτερικό refactoring χωρίς πρακτικό αντίκτυπο μπορεί να παραμένει στο repository history.
Πότε χρησιμοποιείται το “Unreleased”;
Μόνο για επιβεβαιωμένες αλλαγές που έχουν εγκριθεί ή συγχωνευθεί και αναμένεται να διατεθούν στην επόμενη έκδοση.
Πρέπει να αναφέρουμε κάθε security bug;
Αναφέρουμε με ασφαλή τρόπο τις διορθώσεις που είναι χρήσιμες στους διαχειριστές. Οι τεχνικές λεπτομέρειες δημοσιεύονται μόνο όταν δεν αυξάνουν τον κίνδυνο.
Τι γίνεται όταν μια έκδοση αποσύρεται;
Το release note επισημαίνεται ως withdrawn ή superseded, αναφέρεται η ασφαλής έκδοση αντικατάστασης και δίνεται σαφής required action.
Πριν και μετά από update
System Status
Η επόμενη σελίδα παρουσιάζει την κατάσταση των βασικών υπηρεσιών και τον τρόπο ενημέρωσης για incidents και maintenance.