search

hoodiehq / discussion

General discussions and questions about Hoodie
7 stars 1 forks source link

Roadmap #38

Closed janl closed 8 years ago

janl commented 10 years ago

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:

hoodie-plugin-users:

Release 1.0.0:

lenareinhard commented 10 years ago

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.

janl commented 10 years ago

Thanks @fux!

janl commented 10 years ago

moved comprehensive CI into 0.3.0. We need this first. we keep releasing stuff that is broken.

janl commented 10 years ago

0.2.0 shipped thanks @ola! <3

janl commented 10 years ago

Added https://github.com/hoodiehq/hoodie.js/issues/330 to 0.4.0

gr2m commented 10 years ago

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

gr2m commented 10 years ago

fyi: added names and owners to milestones

gr2m commented 10 years ago

fyi: added https://github.com/hoodiehq/hoodie.js/issues/343 & https://github.com/hoodiehq/hoodie.js/issues/311 to PouchDB Milestone (they always have been part of it)

lenareinhard commented 10 years ago

great work, @gr2m! My currently open questions:

gr2m commented 10 years ago

@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.

lenareinhard commented 10 years ago

@gr2m sounds good, let's do this. :)

davidpfahler commented 10 years ago

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"?

inator commented 10 years ago

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?

gr2m commented 10 years ago

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.

boennemann commented 10 years ago

[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 https://github.com/hoodiehq/discussion/issues/38? [18:16:48] @boennemann Hey inator (: These are essentially marketing release numbers. [18:17:13] @boennemann And aside from 1.0 we won't even communicate them, as they're only an internal milestone thingy. [18:17:51] @inator Ok, so how best to distigush between versions of Hoodie? CLI version? [18:18:37] @boennemann That's a tough question. Currently the my-first-hoodie template is the central place where hoodie dependencies are defined. [18:18:43] @inator Also, how do I know that one install is different form the other? [18:19:06] @boennemann The combination of these defines the "hoodie version" https://github.com/hoodiehq/my-first-hoodie/blob/master/package.json#L6-L9 [18:19:12] @inator With so many modules involved.. this seems like it could be dicey [18:20:11] @boennemann It's a matter of strict semver usage [18:20:14] @inator Thanks for that... but ouch "hoodie-server": "^1.0.0", etc... leaves a lot of variables [18:20:30] @inator in terms of what I might actually get [18:20:58] @inator I admit it's a difficult problem to solve [18:22:57] @boennemann Indeed. But as the hoodie-server defines the hoodie.js version, maybe it's best to stick to hoodie-server's version if trying to differentiate [18:23:47] @boennemann And for plugins we have to come up with something, too. I hope the answer is not peerDependencies though :( [18:27:23] @inator What if the CLI itself were used to distinguish releases? [18:28:47] @boennemann Could you elaborate on how you'd do it? [18:31:05] @inator I'm thinking out loud here, but what if the version of the CLI matched the release? [18:31:24] @inator Of course it would require hard set dependancies, at least at the major level [18:32:41] @boennemann The CLI needs a version/release cycle of its own. [18:32:53] @inator yes indeed... [18:32:58] @boennemann An idea would be to have weekly versions [18:33:29] @inator Could the whole thing be packaged differently? [18:33:43] @inator rather than install the CLI... [18:33:53] @boennemann once a week we do an everything latest stable install, take the dependency tree, and refer to it as a version [18:33:59] @inator Install the Hoodie package? [18:34:14] @inator We might be saying the same thing, uh? [18:34:28] @boennemann that would be possible [18:34:31] @inator Weekly would be nice [18:35:05] @boennemann create a new app, take the node_module folder and package it as hoodie version [18:35:20] @inator Exactly. [18:35:39] @inator But with hard set dependancies [18:37:01] @boennemann We are basically takling about this https://github.com/gr2m/milestones/issues/3 + a package [18:38:48] @inator Yes it appears we are. But was that intended for Team use, or the public? [18:39:06] @boennemann both ;) [18:40:01] @inator Ok, so I could then do an "npm install hoodie" or something like that, and would get the latest "marketing" release? [18:40:31] @inator and thus also request a previous version? [18:40:53] @inator like I can do with any run of the mill module [18:41:01] @boennemann that would all be possible then [18:41:08] @boennemann and i like the idea tbh [18:44:04] @inator Just to close the loop... is that github issue you referred me to basically prescibing the same thing? [18:44:16] @boennemann sans the packaing, yes [18:44:45] @boennemann so the version would be marketable, but not installable [18:44:55] @boennemann which is not so hard to fix, as we discussed

inator commented 10 years ago

@gr2m - Thanks for the quick reply. @boennemann and I have been tossing around ideas via IRC and he eventually referred me to https://github.com/gr2m/milestones/issues/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:

 npm install hoodie@<version>

I also like the idea of a weekly release cycle btw. :)

gr2m commented 9 years ago

@janl can we close this?

janl commented 9 years ago

@gr2m uhm no, why?

gr2m commented 9 years ago

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?

inator commented 9 years ago

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:

hoodie new <appname> [-v hoodie-version]

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. :)

On Dec 23, 2014, at 7:53 AM, Gregor Martynus notifications@github.com wrote:

I thought because we have http://gr2m.github.io/milestones/ http://gr2m.github.io/milestones/ now. Do you still use this? It might be rather confusing to have both, don't you think?

— Reply to this email directly or view it on GitHub https://github.com/hoodiehq/discussion/issues/38#issuecomment-67958225.

almereyda commented 8 years ago

Once it ever gets to the launch party, I'd love to donate a massive dub set for the last women standingdancing.

varjmes commented 8 years ago

I'm wondering if this needs updating/changing? Thoughts?