Requirements for a 1.x.y.z release
It has been decided here to adopt for diaspora* avec SemVer system with a prefixed number.
That prefixed number was intended to "be increased at community decision instead of a major release."
With the majors changes introduced in 0.6.0.0 (port to BS3, federation gem, and, maybe, public API), I think the project would benefit from a discussion on the requirements for a public 1.x.y.z release.
IMHO, the major blocking point for such a release is the difficulty of installation and setup for non-developers. The diaspora package partly solves the problem but only on Debian. Here are a few ideas to isier this that could be a part of a milestone for that public release :
a graphic interface for configuration; it should be possible to edit the
.ymlfile directly into the administration section,a grafic setup page for database at the first install; when the source code has been cloned, the server should display a page to let the user configure the database connection before diaspora launches.
an automatic installation of RVM and gems; unhopfully, I have no idea on how to achive this.
other ideas ?
Jonne Haß Wed 22 Jul 2015 7:52AM
I wrote up this https://github.com/diaspora/old_diaspora_wiki/blob/master/Seed-migration-proposal.md once.
Deleted account Wed 22 Jul 2015 7:59AM
Nice. Though, I don't think it would really justify a 1.0 release if the user had to manually backup/import its data. As thae API is currently being develop, I can suggest the migration fonctionnality to be the first feature of it ? This way, a migration could simply take the form of an OAuth application installed on the old account that will be in charge of importing the whole account into tha new pod ?
Deleted account Wed 22 Jul 2015 8:01AM
I like to add that IMHO, an API wouldn't be sufficient to justify a 1.0 release because I mainly see that work as a very long-term work over multiple release, one little step at a time.
Jonne Haß Wed 22 Jul 2015 8:22AM
No, I don't think we should expose things like close account and fetching the private key over the API. That approach also has the huge downside of not going to work if the original pod goes offline. The archive approach can work as a backup you can restore anywhere.
Jonne Haß Wed 22 Jul 2015 8:23AM
And of course the API would need to reach a somewhat stable state first. After all these points are not "hit any and we're good" but "should all most likely included".
Deleted account Wed 22 Jul 2015 8:30AM
like close account and fetching the private key over the API.
I've never intended to expose the close account feature via the API, but about the private key, tha mecanism can stay unchanged from what you described, except that the user does not have to fetch the archive himself in all cases. The archive can be exchanged complitely encrypted between the pods. I'm not sure I see why it would be less secure than the user fetching the archive himself and then uploading it.
Jonne Haß Wed 22 Jul 2015 9:27AM
That you don't see how potentially exposing a high risk feature to all third party clients due to potential bugs in the authorization layer is not so much of a good idea if it can be avoided, is a bit sad.
But anyway, we're getting horrendously out of scope of this discussion, there has been quite some previous talk, please continue there.
goob Wed 22 Jul 2015 1:48PM
“should all most likely included”
indeed. The four items I listed are those I consider essential to have been implemented in a fully working way before v1.0 is considered.
Deleted account · Wed 22 Jul 2015 7:50AM
Five, at most :p
Ok, what is missing for a seed migration ? @jhass : what system do you have in mind for a feature like thins ? Would it take the form of a button "migrate my account to another pod" in the parameters section ?