With a month passed since 2.5.0, I wonder if people would prefer me to dump the current progress in 2.6.0?
Out of 18 features planned for 2.6.0, 9 are done and 3 are almost done. The rest could be postponed to 2.7.0, if there is demand...
Before you ask, the roadmap can be viewed here: https://github.com/tootsuite/mastodon/projects/6
@Gargron Yes please!!
@Gargron yo lo que tú digas, corazón. Pendiente de tus instrucciones estoy (aunque no las entienda).
@gargron Most stuff I'd like to see is still in the "todo" so I'd say to have them in 2.6 too
@gargron
Why not call it 2.5.1?
@Gargron It feels like the number and size of changes done warrant the bump to 2.6 already.
Shlee fucked around and @Gargron Generally I'm a fan of more releases more often/version numbers are mostly pointless
1) What's wrong with a 2.5.1+ style point release after a series of major commits... this requires more work if you're going to run RCs for each of them tho
2) I'd be a fan of moving to a regular release cycle to allow something like "Mastodon 2018.09"
then we could easily see, this server was last updated in "2017.06" or whatever, and have more pressure on the admin to update the damn thing.
@Gargron Si no afecta a la estabilidad, por mi parte adelante
@Gargron hi, I’m new in mastodon but i would like to help you to improve it... if you need some help please let me know... if I know how to do it then I do it
@Gargron features always go in a x.y.0 release. Bug fixes, critical updates, errata are for x.y.z release. For example having features mixed into a x.y.z release schedule is why i had to cherry-pick the account redirect loop out of the repo vs being able to just update
@david Semver is most meaningful for libraries, not end-user facing software
@Gargron Release fast and (not) break things 
awesome progress 
thanks Eugen!