Repository navigation
Please tag a release #4
Description
Activity
At Google the build is continuously treated as releasable. We work exclusively at head. Any in-between points that are not fit for release are either made on private branches or ar flagged off so as not to interfere with production.
You are missing the point of tagging releases. Versions enable the ecosystem around your library to have a stable release point to depend on, write docs around, etc.
The current version is 6909e38. We normally push a new version once or twice a day. There are a lot of codebases that depend on Blockly, so we are very careful about maintaining backwards compatibility.
Google's products generally don't have discrete versions. Such as Closure (https://github.com/google/closure-library/).
As a third party developer outside of Google, it is difficult to consume a library without meaningful version codes. A versioning technique such as http://semver.org/ allows us to stay up to date without picking up breaking changes unintentionally.
The Google approach is to have all code (from Gmail to self-driving cars) in a single code base, with everything at head. That way nobody has to ever worry about versions. There is only one version.
As a result, we are rather careful about not creating breaking changes.
Google Guava is an example of a versioned Google library though: https://code.google.com/p/guava-libraries/
+1 to this. Been burned in the past using "never breaking change" dependencies before, enough so that we'd rather fork a project and create our own repo for it to manage the dependency
Hmm, Guava is an interesting example. It is a subset of the Java core libraries used inside Google. We are unable to keep the externally-published Guava project at head since a lot of manual work needs to go into making sure that confidential or licenced code doesn't end up being published. Thus there is a more traditional release cycle where Google's code is periodically forked, scrubbed, and released. Definitely not the way we like to operate, but in that case necessary.
If you want a "release version" and are afraid of the future, just grab a random commit (e.g. 6909e38) and sync against that. But we've made a commitment not to break existing code, so syncing to head is really best.
@NeilFraser c'mon, the code sample published at https://developers.google.com/blockly/installation/toolbox does not work with current
masterversion of blockly source code. I had to use HTML code from repository, because it was slightly ahead of sample published.Also i prefer to reference some version via webjars, but due to lack of semantic versioning it is currently unknown what to use as a wide-known "version". Git commit hashtag? date-time in some format?
longtimestamp? This confuses a lot.And this "trunk" approach is quite questionable - how do you introduce breaking API changes?
https://developers.google.com/blockly/installation/toolbox does not work with
current master version of blockly source code.Can you elaborate? I copied and pasted each code sample into a test file and they all worked (not counting the fictitious custom blocks in the tree example).
And this "trunk" approach is quite questionable - how do you introduce breaking API changes?
We don't. The last breaking API change that I'm aware of was on 11 March 2013 when we rolled back some badly planned code that had been checked in without review.
Google may have a single code base, but the world doesn't. Until there is a single hash for the entire world of software and every software project in the world is kept perpetually in sync, your argument is ridiculous.
@jroper , i support you thought.
Imagine a corporate environment, let's say some rich global investment bank, with it's own procedures, external regulations, compliance, politics etc. So deployment could happen only twice a year.
So, where should i look for the piece of documentation that was relevant 6 months ago?
Plain tagging source codebase together with corresponding documentation source might help here a lot.
Just to make things clear - you are doing great job, no questions here. Just please provide us the way to effectively use your code in our non-google environments.
And, by the way - what is currently suggested way to include blockly .js files into generic web/html/css/js project? How can i manage this dependency, is it published to jsapi.google.com, or available somehow via brew and likes?
Webjars availability is in place, but only due to the proactiveness and creativity of it's maintainer that is willing (at least for now) to overcome these artificual administrative barriers and non-semantic versioning approach.
@NeilFraser , sure.
Initially i used webjars version with sample provided with documentation.
Then i realized that this SVN version is not relevant, and updated my .js files from github shapshot.Things still did not work, so i found "toolbox" example in github source trunk - only then problems disappeared.
Errors were, AFAIR, about some missing block types.
just now i compared view-source:https://blockly-demo.appspot.com/static/demos/toolbox/index.html with ./blockly/demos/toolbox/index.html - contents are identical. Still no way to see what github commit hash corresponds to currently deployed view-source:https://blockly-demo.appspot.com/static/demos/toolbox/index.html
Maybe in my case i faced an issue that code was commited to github, but blockly-demo instance was not yet refreshed. But due to the lack of any versioning it is impossible to tell this for sure, anyway.
- added a commit that references this issue
on Dec 1, 2015 - added a commit that references this issue
on Jun 29, 2016
Please tag a release