-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Roadmap #38
Comments
fyi: removed the communications topics which hadn't been added by you yourself. Please also remove "Merchendising" and "Blog post series about the making of Hoodie", they don't make sense here if you want this roadmap to be technical-only. |
Thanks @fux! |
moved comprehensive CI into 0.3.0. We need this first. we keep releasing stuff that is broken. |
0.2.0 shipped thanks @ola! <3 |
Added hoodiehq/hoodie#330 to 0.4.0 |
As discussed, I'd suggest to remove The Stripe-Worker from the 1.0 Scope. It's a plugin, that certainly is super nice to have, but not required for 1.0 relaunch |
fyi: added names and owners to milestones |
fyi: added hoodiehq/hoodie#343 & hoodiehq/hoodie#311 to PouchDB Milestone (they always have been part of it) |
great work, @gr2m! My currently open questions:
|
@ffffux let's chat on this tomorrow, ok? I want to replace this issue with something that is easier to handle and provides better insights. |
@gr2m sounds good, let's do this. :) |
Hi all, my two cents on this roadmap: What happens when the "0.8.0 App / Plugin Templates" get done before the "0.4.0 User Plugin"? Do we need to wait for the user plugin to get done, before we get them in the 0.8.0 release? Or will 0.8.0 be released before 0.4.0 (possibly with other actual version numbers!)? This is really confusing to me. What you call releases here to me looks like features (or feature branches). They can and should be developed independently from each other. That's why different people are responsible for them. So, naturally – by simply looking at this – my guess would be that they are developed on different branches or repos, but not "in" different releases. What would that even mean? I understand that 1.0.0 is a special release – both from a marketing standpoint but also regarding semver. However, before 1.0.0 you can have as many 0.x releases as you want. What I'd suggest is to decouple these features from releases. Have features of branches (and/or different repos). Among the benefits is also that you don't need to decide now whether to include the payments plugin in a release or not. You can release features independently form each other. One more point that is dear to my heart: The structure of the roadmap at the moment feels very locked down. Releases are numbered sequentially and assigned to people in the hoodie team. So, where do I, a random contributer, fit in this structure? It doesn't really allow for an "outsider". The underlying waterfall idea, that releases build on top of each other doesn't seem to apply. In other words: I'm seeing a list of operations (the above "releases") that are executed synchronously while they could be executed asynchronously – leaving performance (=progress) on the table. Even if that is not actually the case, that's how it looks like here and how it appears to others. So, can we please change these "releases" into "features"? |
Sorry if I missed this somewhere (and that this is a bit off topic), but how do I actually install a specific release via npm? As I recall, I can target a specific version of the CLI, but a release as noted above? |
The releases listed here are more marketing version numbers. There currently is no way to address a certain version number of hoodie that encapsulates all Hoodie modules, but that is something we are thinking about right now. |
[18:13:48] @inator Hello all - Quick question for any of the community members or team members. When I install Hoodie via npm, how pull down a specific official release version of Hoodie as noted at #38? |
@gr2m - Thanks for the quick reply. @boennemann and I have been tossing around ideas via IRC and he eventually referred me to gr2m/milestones#3. I just want to toss out my support for anything that would result in us being able to do something like this to get the "release" version of choice:
I also like the idea of a weekly release cycle btw. :) |
@janl can we close this? |
@gr2m uhm no, why? |
I thought because we have http://gr2m.github.io/milestones/ now. Do you still use this? It might be rather confusing to have both, don't you think? |
In case this gets closed, I thought I’d chime in one more time on the subject… We’ve resorted to referring to the “my-first-hoodie” template as the version of Hoodie. It’s the place where the modules all come together to deliver Hoodie, and it’s easily shrink wrapped from there. Based on the current Hoodie CLI approach, it seems it would be easy to do this:
Which is nothing more than a template pointer similar to the -t option. If no version argument is supplied, the latest hoodie version gets installed. My thoughts anyway. :)
|
Once it ever gets to the launch party, I'd love to donate a massive dub set for the last women |
I'm wondering if this needs updating/changing? Thoughts? |
We need a single document that tracks Hoodie’s roadmap. This is it. @janl is responsible.
The version numbers here correspond to the entire Hoodie system releases. Individual components have their own version numbers.
Hoodie’s current version: 0.2.0.
The Roadmap:
Release 0.1.0 Document Global Shares:
Release 0.2.0 New Hoodie Admin Dashboard:
Release 0.3.0 Continuous Integration & Release Train (@boennemann):
Release 0.4.0 User Plugin (@caolan):
hoodie-plugin-users:
hoodie.account hoodie#330rethinking hoodie.account #47Release 0.5.0 Payments (@janl) to be removed?:
Release 0.6.0 Security (@caolan):
Release 0.7.0 try.hood.ie (@janl):
Release 0.8.0 App / Plugin Templates (@zoepage):
Release 0.9.0 PouchDB (@gr2m):
Release 0.10.0 *.hood.ie relaunch (@ffffux):
Release 0.11.0 Release Communications (@ffffux):
Release 1.0.0:
The text was updated successfully, but these errors were encountered: