Skip to content
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

Implement a migration system #31

Merged
merged 33 commits into from
Aug 10, 2018
Merged

Implement a migration system #31

merged 33 commits into from
Aug 10, 2018

Conversation

Shinmera
Copy link
Member

@Shinmera Shinmera commented Aug 7, 2018

This implements a relatively simple migration system for Radiance and its users that allows the migration of runtime data to accomodate for incompatible changes. This should fix #30.

Yet To Do:

  • Hook the migration step into the startup sequence
  • Document usage in the README

Shinmera added a commit to Shirakumo/radiance-bootstrap that referenced this pull request Aug 8, 2018
Copy link
Contributor

@jorams jorams left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally seems like a very sane system! After reading up on some things that stood out to me and finding out I just had a wrong mental model of some standard CL functionality, the only comments left are about the documentation.

See VERSION<=")

(function version-bounds
"Returns a subsequence of VERSIONS that is bounded by start and end.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the first description lines of version-region and version-bounds could use some work. If I understand correctly, version-region returns essentially (<= start x end), and version-bounds returns that same subsequence, but ensures it starts with start and ends with end?

Maybe something like this for version-region:

Returns the versions in VERSIONS that are between START and END, inclusive.

And something like this for version-bounds:

Returns the versions in VERSIONS that are between START and END, inclusive, ensuring the sequence starts with START and ends with END, if provided.

T --- The system is migrated to its current system version.
version --- The system is migrated to this specific version.

When this function is called it determines the list of effective
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think "effective" should be replaced with "concrete", which is what it's called everywhere else.

defaults.lisp Outdated
@@ -228,3 +228,29 @@
(T
;; Other refer, no change.
))))))

;;; Default logger to make sure we can log even before the real impl is laoded.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mistyped word "loaded".

@gingeralesy
Copy link

Went through the changes. It seems like a really solid and sensible system to have. If there were any issues, they escaped my eyes and I didn't catch anything wrong with the documentation either. All in all migrate-versions seems really handy to me!

…ntation definitions.

Should fix some upgrade weirdness, I hope.
@Shinmera Shinmera merged commit b223885 into master Aug 10, 2018
Shinmera added a commit to Shirakumo/radiance-bootstrap that referenced this pull request Aug 13, 2018
Shinmera added a commit to Shirakumo/radiance-bootstrap that referenced this pull request Aug 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Version Migration Facility
3 participants