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

Add `spago bump-version` #203

Closed
f-f opened this issue May 16, 2019 · 10 comments

Comments

@f-f
Copy link
Member

commented May 16, 2019

This is Step 1 in the publishing flow described in #142 (comment)

We'd add a spago bump-version $new-version (taking a version number, or patch, minor and major) that would:

  • make sure that some fields necessary for publishing are specified in the spago.dhall: repo, license, version (not sure about this last one, should we get it from the git tag?)
    This means that the people not publishing a library will not have to have these fields defined (i.e. we should have a PublishingConfig type on the Haskell side, and try to conform the config to that instead of the normal Config type)
  • takes the specified version and:
    • makes a git tag out of it
    • bumps the version in the spago.dhall (if we decide that we want the field)
@f-f

This comment has been minimized.

Copy link
Member Author

commented May 17, 2019

Update: @justinwoo clarified to me that when you cut the tag, the bower.json should be versioned and in the root, otherwise the package would be unusable from bower.

So here we have two possibilities (I'm leaning towards the second for sanity of implementation):

  • if we want to absolutely avoid having to version a bower.json: make a dummy temp branch, generate the bowerfile, commit it to the branch, cut the tag on the branch and push that
  • if we want everyone to version a generated bower.json: we generate it after we verify that the spago.dhall has the correct fields, and then check that the git status is clean. If it's not we abort and ask the user to commit everything. We also explicitly check that the bower.json is being versioned by git (the case I'm worried about it people putting the bower.json in .gitignore). Then if everything is fine we can cut the tag
@Dretch

This comment has been minimized.

Copy link
Collaborator

commented Jun 16, 2019

Hi, I can have a look at doing this.

@f-f

This comment has been minimized.

Copy link
Member Author

commented Jun 17, 2019

@Dretch you might want to take a look at the thread in #203, since it contains relevant information for this too

@Dretch

This comment has been minimized.

Copy link
Collaborator

commented Jun 18, 2019

@f-f do you mean #204 ?

My takeaway from reading #204 is that git tags should be used to store the version, rather than having a version in spago.dhall.

@f-f

This comment has been minimized.

Copy link
Member Author

commented Jun 18, 2019

@Dretch yes sorry! And yes, the git tag is one takeaway, and another one is which versions we should generate for packages.
Also you might want to pull in the bower-json package, which also the compiler uses to deal with the bower.json file

@Dretch

This comment has been minimized.

Copy link
Collaborator

commented Jun 18, 2019

And yes, the git tag is one takeaway, and another one is which versions we should generate for packages.
Also you might want to pull in the bower-json package, which also the compiler uses to deal with the bower.json file

Okay, but I was thinking this ticket here is just about generating git tags (and possibly also checking for repo/license fields in spago.dhall) - with the bower.json generation and publishing left to #204 ?

@f-f

This comment has been minimized.

Copy link
Member Author

commented Jun 18, 2019

I thought so too initially, but as I noted some comments above it turns out we have to generate the bower.json here already, otherwise the tag will be unusable from bower (because bower will expect a bowerfile to be present at the tagged commit)

@Dretch

This comment has been minimized.

Copy link
Collaborator

commented Jun 18, 2019

I understand bower.json needing to be present at the tagged commit. I had interpreted the tickets as being dependent - i.e. #203 laying the groundwork (git tagging) and #204 building on top (also generating the bower.json, and publishing).

I don't have a preference either way really. I can generate the bower.json as part of this work.

@f-f

This comment has been minimized.

Copy link
Member Author

commented Jun 18, 2019

@Dretch yeah I'd say it's part of this ticket, because in order for a standalone spago bump-version command to make sense we'll need the bower.json generation to happen here before the tagging (and then when doing spago publish we'll either just check that it's there, or we'll just regenerate it)

@f-f f-f added the in progress label Jun 21, 2019

Dretch added a commit that referenced this issue Jul 7, 2019

@f-f f-f removed the in progress label Jul 10, 2019

@f-f

This comment has been minimized.

Copy link
Member Author

commented Jul 10, 2019

This was fixed in #289, thanks @Dretch!

@f-f f-f closed this Jul 10, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.