Stepping down

[sole]

I have been maintaining this library for more than 6 years. It will be 7 years in May! This is a very long time.

Personally, I am happy with its current status and features, but people want new features and also want to expand it into new directions.

I don't have the time or the interest to contribute to those, but I don't want to be in the way of progress either.

Therefore, I have decided to step down from this project, and allow interested parties to decide the future of the library.

If you use tween.js for your projects, please consider stepping up. Let me know you want to take over. I will help with the transition, answering questions and ensuring you are equipped to drive the project forward, towards the future and beyond 😃 .

If no one has taken over successfully by the end of June 2017, I will declare the project unmaintained, and cease activity on it.

And since I have your attention now, allow me to use this moment to thank a few recent contributors that have generated the bulk of the activity in the last years: Mike @mikebolt has made amazing contributions, @dalisoft has started an ES6 version for those who are itching to live in the future, and @trusktr has also been adding very thoughtful comments like this one.

Thanks to all of them for their help! And thanks to you if you get involved 🙌🏼

[trusktr]

I would be happy to get involved in helping to maintain this and working with others on the ideas from tweenjs/discuss#1.

[dalisoft]

I am too will be happy to maintain and improve library

[trusktr]

@sole How are you envisioning to do it? Do you want to add us as collaborators?

I think you meant to mention @mikebolt in your OP, not @casebolt (although that happens to be Mike's last name! hehe).

[dalisoft]

@trusktr Check out latest es6-tween v1.0.1 release that implements some ideas of your comment.

EDIT: I am want that @sole continue being author of this amazing library.

[trusktr]

I would like that too. Maybe @sole you would be interested in just approving PRs (not necessarily contributing code), or at least designating someone who can accept PRs.

@dalisoft I like the concepts in your ES6 branch. Can we migrate slowly towards that so it is easier than doing a big PR?

I made this first change which adds a simple Babel step: #327

Then after that we can start converting the file itself to ES6 language features (we can pull your ideas in, you can make new PRs), then after that we can eventually just split everything out.

And then finally we can start on v2.

I think it would be good to make gradual PRs on this repo towards something like what you have. What do you think?

[trusktr]

And then finally we can start on v2.

Actually, v2 doesn't have to be one big step, we could do it gradually. We can start using semver, and if we have a breaking change just update the major version number. Similar to what Three.js does with it's releases (except we'd use major numbers). Thoughts on that?

[sole]

Thanks all! and yes I definitely meant @mikebolt (I'll update the post).

When I said step down I really mean step down. I am juggling many things at once on my work and personal life, and I don't have time to review PRs regularly, which turns me into the bottleneck, and that's what we want to avoid here. So yes, my intention is to hand this to other collaborators, and get myself out of the way. I might pop by and help as well, as I will continue using the library, but I don't want to be the single point of failure (or single point of delays 😏)

Re V2: my personal experience is that V1 has many unclear parts and strange timing inconsistencies that manifest from time to time in some specific circumstances (just look at the issues). It's fine for normal usage, and it's good because it's "simple". But it can be weird when working with ES6 objects. I would keep it as it is, 'freeze it', or something similar, and recommend it for people not using advanced features (e.g. in mini-ads, microsites, small projects without a build step, ES5 stuff, etc), and do all the new work on the ES6 project.

If I was to do ES6 I would modularise well from the beginning. And make everything testable and explainable. V1 is not good at that.

Right now publishing to npm is done automatically via semantic-release if tests pass. I need to document that.

I'll file bugs.

[trusktr]

@sole Hehe, you mentioned @casebolt again! 😆

I wouldn't mind if you documented how that semantic-release stuff works, so that I can understand if my changes in this PR will work.

[martikaljuve]

I would also like to help with maintaining this library. I think some changes would make this library a bit easier to maintain:

• Divide the monolith src/Tween.js into separate files for maintainability (e.g. Split tween.js into separate files and bundle it with rollup. #331)
• Use prototypes in TWEEN.Tween (as already done by @trusktr in perf: improve memory usage by storing methods on the Tween prototype #326)
• Split tests.js into separate files per module, possibly also replacing nodeunit with a more standard framework (e.g. tape seems nice)

For a new major version, I would like to see Tween.js use .on event listeners instead of onCallbacks. This could be a gradual transition, e.g.:

Tween.prototype.onStart = function(callback) {
	warn("tween.onStart is deprecated, please use tween.on('start', listener) instead.");

	// Removes other event listeners to have old .onStart behavior
	this._events.removeAllListeners('start');
	this._events.addListener('start', callback);
};

[dalisoft]

@martikaljuve Your suggestion/ideas already implemented in es6-tween (maintaining by me)

[martikaljuve]

@dalisoft, I have been looking at the changes you've made in es6-tween and I think it would be good if the project was instead developed gradually using feature branches, unit tests, pull requests and peer reviews.

Some issues I see in your project:

• development in master branch.
• commit messages are not very descriptive.
• missing tests for added functionality (e.g. TWEEN autoPlay, emit, on, off; TWEEN.Tween pause, createEmptyConst, restart, reverse, seek)
• unnecessary dependencies (e.g. babel-plugin-transform-proto-to-assign, babel-plugin-transform-react-jsx)
• code style and syntax errors
  • jscs reports 50 code style errors (running jscs on src dir instead of dist/Tween.js)
  • jshint reports 28 syntax errors (running jshint on src dir instead of dist/Tween.js)
  • mixed spaces and tabs in package.json.
  • cruft: Tween.checkValidness, unused variables
• src/dist is an unconventional name for a dir.
• package.json "author" should probably attribute all the past contributors instead of just "dalisoft".

I believe you have many good features in your project, we should just gradually introduce them to the main project, with discussion happening on whether a feature is useful/necessary before merging them.

[dalisoft]

@martikaljuve I fixed some of issues in my project, but some of issue #11 are written and no answer. So i fixing if matching bugs, but at least app is working for tween for both npm and browser at ie9+

[sole]

Sorry I've been a bit absent from this (lots other commitments and stuff going on).

I created a @tweenjs scope in npm, so packages can be published under @tweenjs instead of under @sole.
Still need to document the npm publish mechanism as stated here #328

I will follow up there for things such as adding other collaborators to the npm package and scope. Thanks for stepping up!