Can we have someone take over maintenance?
Closed this issue · 8 comments
He's been doing a lot of it already :)
The project needs more regular maintenance attention and some pretty serious ongoing development too, neither of which I'm very set up for at the moment. The people I'd feel good about accepting / driving entirely new features and bigger projects atm would be @judofyr, @josh, and @rkh. Pretty sure everyone's slammed with other stuff.
I don't know I keep hoping to carve out a few days and put my head down on it but that's not really a sustainable way to run a project. I'm definitely open to suggestions.
#ifihadtilt:
1.3.4
I want to merge the latest Template-PRs (RDoc etc.) and release 1.3.4.
1.4.0
I want to figure out the minimal implementation for getting encodings to work properly (#107, #75). We just need something that works for 99% of the use-cases and doesn't blow up (#152). We don't have to solve everything encoding related (e.g. transcoding) at once.
"Issues Zero"
I want to get all issues down to zero. This means that feature requests are going to be handled different. If someone opens an issue about a feature request I'm going to either:
- Implement it and close the issue
- Say "If you send a PR, I'll merge" and close the issue
- Say "We don't want/need it" and close the issue
That way open issues will be actual issues that we can fix. Tilt is a small library. We should be able to solve all issues.
Towards 2.0
I want to work towards moving more Template-definitions outside of Tilt. The current approach doesn't work well (see RDoc 4); we can't maintain Tilt support for X versions of Y libraries. We need to provide a stable API for the Template-class that won't change for the whole 2.x-branch. That way we can continue improving Tilt while leaving the Template-maintenance to the template engines.
As Tilt becomes an ubiquitous part of the Ruby community it's important that we don't end up with versioning conflicts (e.g. a template engine that depends on ~>2.0.0, but a framework needs ~>2.1.0). Therefore we should encourage all template engines to support all 2.x-release (i.e. ~>2.0). The users of Tilt would then be able to lock to specific branches while still having access to all the template engines. This requires careful work on the Template-class: We need to carefully specify what is public and private API; we cannot break public API; if we provide new features, they must be backwards compatible.
My plan for for 2.0 is thus:
- Document the public API
- Release a Tilt 2.0.0 that still ships with all the Template-classes, but has a way for template engines to "override" them
- Mention that we're not going to provide fixes to the built-in Template-classes
- Work with template engines to implement Tilt-support in their code base
- Slowly remove the Template-classes from Tilt
After 2.0
Lots of things we can work on after 2.0:
- Multiple template processing: #121
- Improved encoding support (transcoding)
- Dropping support for old platforms (old JRuby versions, 1.9.1?)
- Performance investigations on newer Ruby versions
Thoughts?
This is just what I want. I am willing to maintain Tilt even if @rtomayko doesn't think this is the best way forward.
That looks like an excellent plan to me, @judofyr. I've added you to the gem owners list too:
https://rubygems.org/gems/tilt
@rkh I can add you as well. Just wasn't sure what email to use.