Προς το περιεχόμενο
  • 0
Συνδεθείτε  
lion2486

Εκδόσεις σε project και versioning

Ερώτηση

Γεια σας. Αναπτύσσω ένα project (σε php, με eclipse και svn) και θέλω να έχω εκδόσεις κατά την ανάπτυξη (για να προσπαθήσω να έχω ενημερώσεις). Η αρχική ιδέα μου ήταν απλά να αποφασίζω πότε θα υπάρχει μια νέα έκδοση (με βάση τα χαρακτηριστικά) και να την ανανεώνω χειροκίνητα στα αρχεία. Μια άλλη ιδέα μου είναι αν μπορώ κάπως να κρατάω την έκδοση του SVN και από αυτή να παράγω την έκδοση του project. Αυτό μου ακούγεται πιο απλό και σωστό αλλά δεν ξέρω αν γίνεται κάτι τέτοιο και αν ναι πως. Αν υπάρχει καμιά άλλη ιδέα ευπρόσδεκτη. Ευχαριστώ.

Κοινοποιήστε αυτήν την ανάρτηση


Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες

3 απαντήσεις σε αυτή την ερώτηση

Προτεινόμενες αναρτήσεις

  • 0

Σε γενικές γραμμές εσύ αποφασίζεις το πότε θα βγάλεις νέα έκδοση. Δες εδώ αν θες να πάρεις ιδέες για την ονομασία των εκδόσεων.

 

Επίσης είναι πάντα μια καλή σκέψη να αφήσεις το Subversion και να πας σε ένα DVCS όπως το git ή το mercurial. Με τον τρόπο αυτό θα μπορείς να έχεις πιο περίπλοκα, αλλά και πιο ευέλικτα workflows όπως το git flow

Κοινοποιήστε αυτήν την ανάρτηση


Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες
  • 0

Υπάρχουν διάφοροι τρόποι με τους οποίους μπορείς να χειριστείς το lifecycle των διαφόρων εκδόσεων κάποιας εφαρμογής, αλλά η εκμάθησή τους είναι μια δύσκολη διαδικασία γιατί πολλά πράγματα δε μπορείς να τα εκτιμήσεις προτού τα χρησιμοποιήσεις, αλλά και δεν πρόκειται να φανταστείς από το πουθενά να τα χρησιμοποιήσεις προτού τα εκτιμήσεις. Τις περισσότερες φορές λοιπόν το πιο εύκολο είναι να δεις πώς γίνεται αυτό σε κάποιο μεγάλο project για να μπεις σε ένα λούκι και μετά στην πορεία θα αποκτήσεις εμπειρία για να σκεφτείς εναλλακτικούς τρόπους οργάνωσης.

 

Ένα "απλό" σύστημα είναι το εξής:

  • το HEAD είναι πάντα η τελευταία development version και τον περισσότερο καιρό είναι ακατάλληλο για διανομή
  • κάθε φορά που κάνεις release κάνεις πάντα tag το revision από το οποίο προέρχεται η release ούτως ώστε να μπορείς να επανέλθεις σ' αυτό όταν σου πει κάποιος "αυτό το bug το είδα στην 1.3.8"
  • κάθε φορά που κάνεις release ένα major version κάνεις πάντα branch στο σημείο του release (δηλαδή όταν π.χ. κάνεις release την 1.3 θα κάνεις π.χ. ένα tag FOO_1_3_0 και ένα branch FOO_1_3_DEV τα οποία εκείνη τη στιγμή θα αντιστοιχούν στο ίδιο revision)

Το πρόβλημα σ' αυτές τις περιπτώσεις είναι το τι κάνεις όταν έχεις ένα patch στο FOO_1_3_DEV το οποίο πρέπει να περάσει και σε άλλα branches (π.χ. στο FOO_1_4_DEV αλλά και στο HEAD), γιατί βέβαια δε θέλεις ούτε να υπάρχει περίπτωση να ξεχάσεις να το κάνεις και μετά να μην το ξαναθυμηθείς ποτέ (ενώ από την άλλη το σχετικό bug "φτιάχτηκε στην 1.3") αλλά ούτε και γίνεται να θυμάσαι τι έκανες merge, τι δεν έκανες, και τι δεν γινόταν με merge γιατί ο κώδικας στο HEAD έχει αλλάξει και θέλει τελείως άλλο patch.

 

Εκεί λοιπόν στα πολλαπλά merge από κάποιο branch σε άλλο κατά τη διάρκεια ζωής του πρώτου είναι που γίνεται της κακομοίρας και μπορούμε χαριτολογώντας να πούμε ότι όλες οι λύσεις είναι εξίσου κακές.

 

Σ' αυτό το σημείο μπορείς να διαβάσεις όλο αυτό το κεφάλαιο από το svn book και να αποκτήσεις μια καλύτερη ιδέα για τις πιθανές προσεγγίσεις.

 

Τέλος, αν πας σε DVCS τότε και πάλι υπάρχει γραφειοκρατία αλλά τουλάχιστον δεν καταλήγεις σε περιπτώσεις όπου πρέπει να κάνεις κάποια πράγματα manually και με ευλαβική προσήλωση προκειμένου να μην τα βρεις μπροστά σου αργότερα.

Κοινοποιήστε αυτήν την ανάρτηση


Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες
  • 0

Αρχικά ευχαριστώ πολύ για τις απαντήσεις σας. Διάβασα αυτά που μου δώσατε, όσον αφορά την εκδόσεις και την ονομασίες τους η γενική ιδέα είναι να την ανεβάζεις ανάλογα με το πόσες αλλαγές και προσθήκες υπάρχουν (σύμφωνα με το milestone) και υποονομασίες (a-b-rc) για τις διορθώσεις, αλλά ακόμα νιώθω μπερδεμένος, σχετικά με τις μεγάλες εκδόσεις οκ κρατάς μια λίστα με νεα πράγματα, και όταν τελειώσουν την ανεβάζεις, αλλά όταν γίνονται πολλές διορθώσεις θα βγάλεις έκδοση με τις διορθώσεις; σε κάθε διόρθωση; Το να χρησιμοποιήσεις την revision δεν είναι τόσο αντιπροσωπευτικό. Τώρα για τα branches και τα tags δεν καταλαβαίνω γιατί να χρειάζεται να κάνεις branche όταν βγάζεις μια έκδοση, υπάρχει λόγος να διορθώνονται οι παλιές εκδόσεις (δηλαδή να δουλέψεις πάνω στο tag/branche) ή απλά στο trunk και σε κάθε έκδοση να ζητάς τους χρήστες να αναβαθμίζουν στην τελευταία έκδοση; Το branche ακόμα μου φαίνεται λίγο άχρηστο, συνεννοούμαστε και μένουμε στο trunk και δουλεύουμε (ή αν δεν έχουμε κάτι τελειωμένο το προχωράμε σε working copy).

 

Υ.Γ.: χρησιμοποιώ το assembla και δεν μου φαίνεται πολύ βολικό να αλλάξω το svn σε git τώρα...

Κοινοποιήστε αυτήν την ανάρτηση


Σύνδεσμος στην ανάρτηση
Κοινοποίηση σε άλλες σελίδες

Δημιουργήστε έναν λογαριασμό ή συνδεθείτε για να σχολιάσετε

Πρέπει να είστε μέλος για να αφήσετε σχόλιο

Δημιουργία λογαριασμού

Εγγραφείτε με νέο λογαριασμό στην κοινότητα μας. Είναι εύκολο!

Εγγραφείτε για έναν νέο λογαριασμό

Σύνδεση

Έχετε ήδη λογαριασμό; Συνδεθείτε εδώ.

Συνδεθείτε τώρα
Συνδεθείτε  
×
×
  • Δημιουργία νέου...

Χρήσιμες πληροφορίες

Με την περιήγησή σας στο insomnia.gr, αποδέχεστε τη χρήση cookies που ενισχύουν σημαντικά την εμπειρία χρήσης.