Release and version management

[niklauslee]

Hi,

I'm doing my open source project using JerryScript over one and a half year. Sometimes I need to upgrade JerryScript from the git code base.

But, I'm worry about integrating just most recent commits, not official release. There is no official release since Sep. 2016 (v1.0). And, it is also hard to identify what are actually changed because there is no "Release Notes".

So I would like to suggest more frequent releases (about monthly - recommend agile development process like scrum) with fine-grained versions like "1.0.3", "1.1.0", "1.2.0", "1.3.0" and so forth (semver would be great).

This would be very helpful for the many JerryScript fans :)

Thanks,

[LaszloLango]

@niklauslee Hi, we are preparing the next release these days (#2213). Feel free to comment on it. We will provide release notes for it. Unfortunately I cannot define any deadline for the next releases.

[niklauslee]

@LaszloLango It's good news you're preparing 2.0 version. But I'm not talk about the new version, but about release and version management.

Source codes, API docs and release notes should be managed with a firmed version number. Recently I was suffered from the changed APIs after integrating the most recent commits. Current API doc is for which version? According to the semantic versioning, API changes should increase the major version number. I don't know what is the release and versioning policy for JerryScript.

JerryScript is a very nice project, so I wish you to give more considerations on release and version management for many other projects using JerryScript if this project is not only for Samsung's internal project.

Thank you.

[zherczeg]

Improving versioning would be very cool! Since we are small in numbers, it would be good to have help on this. Are you interested @niklauslee?

[akosthekiss]

To put in my two fillérs' worth, I'd like to emphasise the meritocracy-based character of the project. I'm happy to see suggestions for improving the governance (including the releasing and versioning) of the project. But I'm happier to see technical contributions first (e.g, code improvements, pull requests) and then community work (e.g., voluntary feedbacks and reviews) to establish track record, recognition, and status within the project's community. Vote in decision making should only come afterwards, IMHO.

As for this current case, I think we all know the idea behind semver, also that of scrum. The question is whether those parties who put effort in the development of the project are OK with using the tip of tree and git hashes (let's call it rolling release) or feel the need for a more regulated versioning. Even if a more frequent releasing system is implemented, some questions are there to be answered:

• Is semver the best approach? We do introduce API and/or snapshot format changes now and then. Are we OK with quickly increasing major version numbers? There are alternatives, e.g., date-based versioning. Pros and cons should be analysed.
• Is anyone willing to put effort in supporting old versions after they are released? Backporting fixes is quite an overhead. The separate development of various branches is even more so. Or, would versions be just tags on the master branch?

Notes:

• Because of the nature of the project and of the use cases currently known to us, the project is not in any packaging system and is used directly from sources, usually via git submodules. In these cases, git itself handles versioning. Sort of.
• Releases and versioning alone don't solve the integration problems of projects using JerryScript. In case of breaking changes, users have to adapt anyway.

[niklauslee]

@zherczeg Sorry I don't know what can I do. At this time, the only thing I can do is to give feedback about bugs and issues I found by using JerryScript.

@akosthekiss I'm not arguing that JerryScript project need to adopt perfect or very advanced release and version management. I just want to indicate there was no releases too long time (almost two years after 1.0 version). I think it's extraordinary for very active projects.

Please don't look too hard and be simple. I'm not complaining that I was suffered from the integration. I just need a "baseline" to integrate and want to know what are changed at the "baseline". Currently only v1.0 or the most recent commits. There are too many changes and commits between the two.

[akosthekiss]

We are at a stage when we want to put versioning and releases more into focus (we do acknowledge the need for improvement), and we have some clearer ideas about how we think it might happen. Closing this issue in favour of #3104 .