Roadmap about discussion

[lenareinhard]

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]

Thanks @fux!

[janl]

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

[janl]

0.2.0 shipped thanks @ola! <3

[janl]

Added hoodiehq/hoodie#330 to 0.4.0

[gr2m]

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]

fyi: added names and owners to milestones

[gr2m]

fyi: added hoodiehq/hoodie#343 & hoodiehq/hoodie#311 to PouchDB Milestone (they always have been part of it)

[lenareinhard]

great work, @gr2m! My currently open questions:

• where do we add the release process? (wrap it around every release? / …?)
• regarding how detailed this release plan is supposed to be (in this case for docs + communications): I'd aim for adding all details here so people get an overview, but leave the detailed timing out to make it not too confusing, if this works for you.

[gr2m]

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

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

[davidpfahler]

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]

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]

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]

[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?
[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 gr2m/milestones#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]

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

 npm install hoodie@<version>

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

[gr2m]

@janl can we close this?

[janl]

@gr2m uhm no, why?

[gr2m]

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]

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 [email protected] 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 #38 (comment).

[almereyda]

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

[varjmes]

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