semantic-release sucks

[ff6347]

Hi @vogelino having all that semantic-release/travis stuff in there sucks.

It gives me the following error

> extendscriptr@1.1.0-semantically-released semantic-release /path/to/extendscript/extendscriptr
> semantic-release pre && npm publish && semantic-release post

semantic-release WARN pre semantic-release didn’t run on Travis CI and therefore a new version won’t be published.
semantic-release WARN pre You can customize this behavior using "verifyConditions" plugins: git.io/sr-plugins
semantic-release ERR! pre Failed to determine new version.
semantic-release ERR! pre ENOCHANGE There are no relevant changes, so no new version is released.

[ff6347]

Do you have any solution for that? If not I will remove that.

[vogelino]

This means that you are not commiting the way semantic Release expects you to. There is an npm script that is called "commit". When you run this command, you will be brought to a prompt. There you will be asked what kind of changes you entered and if there where breaking changes. This will format your commit message in a way that semantic release is able to determine the right version number for you. This is quite convenient as it assures consistent commit messages and allows you to automate versioning. Also based on this, you could autogenerate a change log, although this isn't implemented yet.

I would recommend you to change something trivial and to commit it with the npm run commit command for the sake of fixing your problem right now. Make sure to add a breaking change or a feature in the commit prompt.

More about this is to be found in the documentation of the packages called commitizen and of semantic release.

I hope this will help.

Cheers.

Le mer. 21 déc. 2016 à 09:43, Fabian Morón Zirfas notifications@github.com a écrit :

Do you have any solution for that? If not I will remove that.

— You are receiving this because you were assigned.

Reply to this email directly, view it on GitHub https://github.com/ExtendScript/extendscriptr/issues/29#issuecomment-268467763, or mute the thread https://github.com/notifications/unsubscribe-auth/ACoarDNaqWNucrQsAYRkRIk1IMJVHARFks5rKOa4gaJpZM4LSs6h .

[ff6347]

yeah well. This should be documented though.

[vogelino]

https://github.com/ExtendScript/extendscriptr/blob/master/README.md#publish-with-semantic-release-and-conventional-commits

Le mer. 21 déc. 2016 à 10:53, Lucas Vogel contact@vogelino.com a écrit :

This means that you are not commiting the way semantic Release expects you to. There is an npm script that is called "commit". When you run this command, you will be brought to a prompt. There you will be asked what kind of changes you entered and if there where breaking changes. This will format your commit message in a way that semantic release is able to determine the right version number for you. This is quite convenient as it assures consistent commit messages and allows you to automate versioning. Also based on this, you could autogenerate a change log, although this isn't implemented yet.

I would recommend you to change something trivial and to commit it with the npm run commit command for the sake of fixing your problem right now. Make sure to add a breaking change or a feature in the commit prompt.

More about this is to be found in the documentation of the packages called commitizen and of semantic release.

I hope this will help.

Cheers.

Le mer. 21 déc. 2016 à 09:43, Fabian Morón Zirfas < notifications@github.com> a écrit :

Do you have any solution for that? If not I will remove that.

— You are receiving this because you were assigned.

Reply to this email directly, view it on GitHub https://github.com/ExtendScript/extendscriptr/issues/29#issuecomment-268467763, or mute the thread https://github.com/notifications/unsubscribe-auth/ACoarDNaqWNucrQsAYRkRIk1IMJVHARFks5rKOa4gaJpZM4LSs6h .

[ff6347]

Still not satisfied :P

[vogelino]

What would you suggest? If your solution is dropping semantic release because it feels like sucking I wouldn't be satisfied either. :D

[ff6347]

Well it shouldn't be that hard to release a new version. I need to learn some wired statements from semantic-release just to push to the main repo. Can't be…

[ff6347]

Added breaking changes and used git-cz and all that. Still can't push to the main repo.

Error:

semantic-release WARN pre semantic-release didn’t run on Travis CI and therefore a new version won’t be published.
semantic-release WARN pre You can customize this behavior using "verifyConditions" plugins: git.io/sr-plugins
semantic-release ERR! pre Determined version 1.0.0 as "latest". Not publishing in debug mode. { type: 'major', version: '1.0.0' }

[vogelino]

Yes you have to learn once that you need to run "npm run commit" instead of "git commit". Then you have to discipline yourself to write good commit messages (which you should do anyway). After that, it makes sense to me that you do not publish any new version that has no new feature, neither fixes a bug nor has a breaking change. And instead of making sure on your own, the script versions it for you, makes sure all tests are successful on Travis (because you should test your code :P) and then publishes a new version on npm and all that with one command.

I understand that such advantages may have been poorly documented on the README but I'm still convinced that we should keep all this.

Now that you know it shouldn't be much of a problem right?

[vogelino]

Well the other problem seems to be about Travis. You should look at why the Build is not running correctly on it. I'll have a look also, but I have to leave soon. If it doesn't work, set manually the version in the npm package and publish it like that and remove the version after that.

[ff6347]

I added changes. Used npm run commit, understand the idea of running test (BTW travis can't run test against Adobe applications it can only build the files) but still the fully automated process seems not to work.

[vogelino]

There are some errors in the travis build: https://travis-ci.org/ExtendScript/extendscriptr/builds/185729891

Although it seem to have passed. Well I have no more time to check this. I'm sorry to see you that negative about this. Errors happen, it's part of the coding process and automation always comes with some caveats and has to be maintained. It's been a long time since I set up the semantic release and as you didn't use it before, things may have change. I don't know.

I will give it a try later. For know, I created a branch based on master called semantic-release to save my config with semantic release and all that. You can remove it on master and do it the old-school way there.

Sorry again for the burden it seems to have caused.

[ff6347]

I totally get the idea of automating the process. I also get that errors happen. The problem I see here is that we both don't have the time to properly maintain this project and updates happen from time to time. Having to dig through the docs of travis and semantic-release hinders us more than it benefits us (IMHO). We still can use semver the old school way by thinking about what we commit.

Also: Developing for extendscript is an edge case and a lot of it can't be tackled with development tools aimed at node or or the web. Running just build test is not enough for this. We still need to manually verify that the code generated runs in Adobe applications. Which can't be done by travis.

[vogelino]

I get your point. We could start a big debate again and again but it would probably not lead to a solution that makes everyone happy. I would just suggest to open issues with less complaining names than "X or Y sucks" :no_mouth: and maybe propose some ideas of fixes.

That said, I suggest that you remove commitizen, conventional change log and semantic release. Then you should add a version in the package.json to be able to publish the package again.

[ff6347]

Yeah. Sorry. I did use the std npm way and had a bad week. Sorry for that.

[vogelino]

It's alright ✌️. I guess I got somehow a little sensitive about this :grimacing:. Let's do it the simple way for now. We can reconsider an automated process later and make sure it'll be more bullet proof and provide better error messages.

Cheers.