application: increment version number on bundle generation (#88373) #119
No reviewers
pmarillonnet
Labels
No Label
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: entrouvert/hobo#119
Loading…
Reference in New Issue
No description provided.
Delete Branch "wip/88373-application-version-number"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
WIP: application: increment version number on bundle generation (#88373)to application: increment version number on bundle generation (#88373)@ -27,0 +59,4 @@def get_cleaned_number(self):number = [int(n) for n in self.cleaned_data['number'].split('.')]number.append(int(now().strftime('%Y%M%d')))Dans la doc du format mangé par
strftime(https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior) on dirait que%Mc’est les minutes de l’heure en cours, sur deux chiffres entre 00 et 59. Je crois que c’est%mqu’on veut ici.zut, oui :)
@ -397,3 +396,1 @@self.initial['number'] = version.numberself.initial['notes'] = version.notesreturn super().get_initial()kwargs['latest_version'] = self.app.version_set.order_by('last_update_timestamp').last()Pas compris pourquoi on prend le soin d’aller chercher la version dernièrement modifiée alors que le soin apporté à la cohérence des numéros de version fait qu’il suffirait d’aller prendre celle dont le champ
numberest le plus élevé (?)C'est pareil, la dernière modifiée est désormais aussi celle qui a le numéro de version le plus élevé. Avant c'était saisie libre on pouvait très bien revenir en arrière (et mettre "toto" si on voulait)
Ok et donc j’imagine qu’il y a encore en base des numéros saisis librement et qui échappent à cette conservation du tri <horodate de dernière modification> ↔ <numéro de version>. Ok.
31dabe34batod123e136ffVu tes modifications sur le format de strftime. C’est bon pour moi. Ack.