If I'm understanding Dave's idea, we're talking about creating a script that would generate the tarball which would exist as part of the repo. So it should be possible from that point forward (i.e. once the script exists) to (re)generate a tarball at any given commit as needed. I think it would be possible retain the old tarballs (with versioned filenames) for at least some period of time (i.e. several years) as this isn't something that needs to happen for each commit so it should be a manageable number of archives.

Realistically, I think we'd need to do it now (and possibly a handful of more times as needed to resolve any issues) to get the updated package into Debian testing, again to get squeak-vm and opensmalltalk-vm playing nicely together[1] and then not likely again until we need to prepare for the next Debian stable (again, with potentially a few iterations to resolve any issues discovered during packaging) Being largely in maintenance mode, squeakvm is a relatively slow moving code base so aside from the rare issue, I don't think it's necessary to try to keep the Debian package up to the minute.

Does this make sense?

[1] Just to keep things simple, it probably makes sense to defer that discussion until we get the squeak-vm package current again. Also, it helps to keep the moving pieces to a minimum since I'm not yet to a 'final draft' version of the initial opensmalltalk-vm package.

You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.