changelog up to date? Merge develop into master?

[ff6347]

I guys. I just saw that Marius Watz is giving a Basil.js workshop in November --> https://twitter.com/mariuswatz/status/796816489718448128

I promised to at least have a 2.0 draft if they want to use it. (Here it is https://github.com/basiljs/basil.js/tree/2.0 ) So I'd like to give him a heads up on new features and all the bug fixes. Is the changelog still up to date? And should be merge the develop branch into master?
What brings me to another thing. We really should update the docs #56 #61 and I think at least bump the version not only a patch but a minor.

[b-g]

OK + good idea. Merging with master and bump the version is fine for me.

I can take care of the changelog today (should I update the one in dev or in master?) ... but won't have time updating the docs (never did it and out of office until Thursday next week).

[b-g]

@fabianmoronzirfas can you also go through the issues and check whether closing makes sense (did that yesterday too, had the feeling there is some solved stuff open which I'm the wrong one to close)

[ff6347]

I can take care of the changelog today (should I update the one in dev or in master?)

Well if we keep it the dev-->master way It should be done in dev and then merged in master. Don't forget to run the npm run release task.

About the docs. An intermediate solution would be building the docs with the latest yuidocs and serve it as github pages until @ludzeller or @ffd8 has the time to update the site.

[trych]

So does that mean we release 2.0 now? Or is this some sort of 2.0 alpha and we'll add more features/bug fixes until the final 2.0 is released? Because there are a whole lot more features that we planned to add for 2.0.

[ff6347]

It's more like an alpha. I think the main idea in 2.0 was to get rid of the b. and make it portable. Adding features could also have be done in 1.xxx.

To really release 2.0 we need to update the docs and all that. Means a lot more work. 😞

[trych]

To really release 2.0 we need to update the docs and all that. Means a lot more work. 😞

Yes, exactly, that's why is was worried there for a second that we rush this step now and call it the 2.0 release, since I would consider the code atm to premature to fully release.

If we do the current state as an alpha to have it ready for Marius' workshop that's fine, but I would hold off with the actual release until we have taken out b. and fixed all the main bugs. Also to make a proper "re-launch" of the site and announce the all new version 2.0. 😃

[b-g]

Same here please no 2.0 for this ... so it will be version 1.1.0 ?
(will go over the changelog now)

[ff6347]

so it will be version 1.1.0 ?

Yes I would suggest that. The patch number should actually only be bug fixes and stuff. Each new feature should get a minor number and breaking changes get a major number. This is how I understand semver.

So the introduction of size and gradient mean actually v1.2

[ff6347]

So the introduction of size and gradient

Did we add more new features? @trych you did a lot PR's lately would you say new features or just patches?

[trych]

b.LOREM and b.placeholder() and I would also consider "Make basil.js fully movable" a new feature.

But that aside, should we not also list bug fixes in the changelog? When I check out a new vesion of a software I am always really interested in reading about bug fixes.

[ff6347]

oh so how to proceed? making it v 1.5?

[ff6347]

hm got yuidoc to build the the docs but it is not pretty. :-/

[trych]

?
Why do we need to jump up in version numbers so much? If the most recent version was 1.0.10, then the next one should be 1.1.0. There can be any number of features and bug fixes in a single version.

[ff6347]

That's why I asked. If we stick to semver I think it should be 1.5 http://semver.org/#spec-item-7

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible manner, and
3. PATCH version when you make backwards-compatible bug fixes.

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API. It MUST be incremented if any public API functionality is marked as deprecated. It MAY be incremented if substantial new functionality or improvements are introduced within the private code. It MAY include patch level changes. Patch version MUST be reset to 0 when minor version is incremented.

We should have bumped the minor version by each new feature. IMO

[trych]

Hm, sorry, I missed the semver part, did we somewhere agree on this? To me this seems quite excessive.

I would just always bump it up by one minor version if we feel the need to make a release, no matter how many features we have put in. If we have only made bug fixes, bump it up one patch version instead.

But that's just my opinion.

[trych]

Minor version Y (x.Y.z | x > 0) MUST be incremented if new, backwards compatible functionality is introduced to the public API.

Actually, as I understand that, this only means whenever the developers decide on a release, then you have to check if new functionality was introduced, and if this is the case (no matter how many new features), then you bump it up by one minor version.

This does not mean that whenever we add a new feature in develop that we need to bump up the minor version or need to keep exact count of how many features we have added. Only the releases are relevant and then you check if it's case 1, case 2 or case 3 and bump up accordingly.

[b-g]

Here is the changelog update: https://github.com/basiljs/basil.js/blob/741780250006b0c6bec6af4959707bedf8ba01f0/changelog.txt

Please add/change/improve it ... if I missed anything

[ff6347]

Added 3 comments. Everything else looks great.
On the version I go with @trych lets do it 1.1 but still keep the semver in mind

[b-g]

OK 1.1 it is. Change changelog as suggested. As I'm off now ... plz and merge on your own.

Have a nice weekend! + Many thanks for the super cool work!! Extremely looking forward to 2.0!!

[ff6347]

okidoki. I'll do the develop --> master merge and bump to 1.1 Have a nice weekend too.

[trych]

One more thing (sorry), would it not make more sense to actually name people by their non-Github name (Timo Rychert instead of @trych), because the change log is also (or mostly) being read outside of Github, I guess?

[ff6347]

I'm cool with GitHub user names. If you like to change it.

[trych]

In all other instances people are called by their actual name, (see line 52 + Added b.arc() by Ken Frederick, cheers mate!) so I would prefer this as well. It just does not make any sense to read @trych at the basil.js website. So, is it okay I change both of the names, then?

[b-g]

@trych Sure! Maybe go with Timo Rychert @trych to have the best of both worlds? Plz update on your own. Cheers

[trych]

Ok, went ahead and changed it.

@fabianmoronzirfas But what about the docs?

hm got yuidoc to build the the docs but it is not pretty. :-/

True, the default yuidoc results look super ugly. Is there any way to get a hold of the basiljs.ch style sheets or so? Or alternatively to apply some clean standard styles for the moment? I'm not very skilled in web design things, as I just started to learn some html basics last month 😜 .

[ff6347]

I'll try to come up with a solution next week.