-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Infastructure for proper versioning. #2500
Conversation
af11aec
to
581e67e
Compare
You see the release workflow going on here right? 134 has the logic in bash to remove the role based on upgrade_roles from the iiab_state.yml file just like runrole --reinstall does for a single role. Could be done in other places but lets start with this in place to have something to test against? |
This PR was tagged with "question" a week ago, with no question asked. What is the deal here? |
Let's surface exactly these design/architectural questions and needs for this PR and others (PR #2511 and others) during our Thursday 10AM NYC IIAB Calls (http://minutes.iiab.io) so everybody can understand where changes like this are critically important, how they serve specific implementer/field communities's needs, medium-term versus long-term etc. All hugely important questions. Keeping in mind that IIAB 7.2 should ship this month with very few changes, if possible (i.e. most all structural/design changes should really target IIAB 8.0 at this point). No rule is completely hard & fast -- but as stated at http://minutes.iiab.io -- we should try to keep those remaining IIAB 7.2 pre-release changes bounded in these 3 rough categories: (if at all possible!!)
|
The general idea is to use iiab_revision in conjunction with tagging|branching to denote an easy a point in time reference of the code-base without resorting to git hashes. |
This goes into 7.2 or the freebies stop. |
693aa30
to
6297f40
Compare
…n iiab_revision to denote the addition
c604f3d
to
d94896a
Compare
d94896a
to
22b8fda
Compare
do_reinstall will denote a major upgrade path in the future
is the proposal to track revisions by role or by entire install? |
By the role |
@holta Get off your high horse you power freak. |
Despite the childish attempt to block testing progress by reverting this commit /iiab/iiab-factory#134 proved to be a success http://sprunge.us/YlHp09 note the order of entries in /etc/iiab/iiab_state.yml the 3 roles were automatically upgraded as the new entries are below calibreweb_installed, the last role to possibly be installed on a machine that was first installed on July 20. |
Add the recording of IIAB_REVISION to stage 9 to allow incriminating the value to reflect major change in a role that would require a re-install where such roles would be recorded in upgrade_roles, works with iiab/iiab-factory#134
Change the value for any roles' source version that would require a re-install, that gets noted in upgrade_roles and iiab_revision gets bumped. The big mongodb change is a perfect test subject.