Feature: Add dinobuildr version tracking #144

New issue

Open

opened 2018-12-20 09:55:36 -08:00 by n3philim · 3 comments

n3philim commented

2018-12-20 09:55:36 -08:00

(Migrated from github.com)

With #143 we've come to a point where earlier versions of dinobuildr.sh will no longer be able to communicate with the information on Github.

Adding in versioning of some sort whether a 2.0.0 or 2018.12.20.a form is used and inserted into dinobuildr.sh and perhaps also dino_engine.py would make it easier to confirm with the team that everyone is using a compatible version of the script.

Going with a strictly numeric version system would mean that we'll need to assess what level of changes count for Major, Minor, and Incremental versions.

With #143 we've come to a point where earlier versions of dinobuildr.sh will no longer be able to communicate with the information on Github. Adding in versioning of some sort whether a 2.0.0 or 2018.12.20.a form is used and inserted into dinobuildr.sh and perhaps also dino_engine.py would make it easier to confirm with the team that everyone is using a compatible version of the script. Going with a strictly numeric version system would mean that we'll need to assess what level of changes count for Major, Minor, and Incremental versions.

n3philim commented

2018-12-20 16:07:38 -08:00

(Migrated from github.com)

With QuickLook it would be easy to have a version comment added into dinobuildr.sh that would be readily visible when previewed from Finder (so it is a 2 second check).

@luciusbono I'm not sure who else we should loop into this discussion. It would be nice to get it set up and synced into the main dinobuildr.sh script, and add in a "requires dinobuildr.sh version xyz or up" in dino_engine.py. With QuickLook it would be easy to have a version comment added into dinobuildr.sh that would be readily visible when previewed from Finder (so it is a 2 second check).

luciusbono commented

2018-12-20 16:14:06 -08:00

(Migrated from github.com)

Strong +1. We considered doing this with a hash initially.

Original proposal was we hash dino_engine.py and include this in the dinobuildr.sh script. If the hash doesn't match, we break upstream compatibility. Quick pros and cons off the top of my head:

Pros

"Safe", since we aren't just blind-curling the main script file like we are today
Easy to implement, since we hash most stuff already

Cons

Would require that we rarely touch dino_engine.py which means config files
There are lots of changes that wouldn't break upstream compatibility (editing a comment, for example) that hashing would break.

I'm torn, because I think semantic versioning is probably the way to go here, but having an upstream hash check would be really nice, since we are just blind firing a curl command (albeit a curl command we trust).

I think the ultimate future for this is a signed package that kicks dinobuildr off or a signed GUI app thing that just looks upstream and does a semantic version check.

Strong +1. We considered doing this with a hash initially. Original proposal was we hash `dino_engine.py` and include this in the `dinobuildr.sh` script. If the hash doesn't match, we break upstream compatibility. Quick pros and cons off the top of my head: #### Pros - "Safe", since we aren't just blind-curling the main script file like we are today - Easy to implement, since we hash most stuff already #### Cons - Would require that we rarely touch `dino_engine.py` which means config files - There are lots of changes that wouldn't break upstream compatibility (editing a comment, for example) that hashing would break. I'm torn, because I think semantic versioning is probably the way to go here, but having an upstream hash check would be really nice, since we are just blind firing a curl command (albeit a curl command we trust). I think the ultimate future for this is a signed package that kicks dinobuildr off or a signed GUI app thing that just looks upstream and does a semantic version check.

luciusbono commented

2018-12-20 16:16:06 -08:00

(Migrated from github.com)

@luciusbono I'm not sure who else we should loop into this discussion. It would be nice to get it set up and synced into the main dinobuildr.sh script, and add in a "requires dinobuildr.sh version xyz or up" in dino_engine.py.

With QuickLook it would be easy to have a version comment added into dinobuildr.sh that would be readily visible when previewed from Finder (so it is a 2 second check).

This is a cool idea. Do you think this is more of a priority than config files?

> @luciusbono I'm not sure who else we should loop into this discussion. It would be nice to get it set up and synced into the main dinobuildr.sh script, and add in a "requires dinobuildr.sh version xyz or up" in dino_engine.py. > > With QuickLook it would be easy to have a version comment added into dinobuildr.sh that would be readily visible when previewed from Finder (so it is a 2 second check). This is a cool idea. Do you think this is more of a priority than config files?