Release Cycle and Support

[alganet]

We need to discuss this! @augustohp and @henriquemoody

[henriquemoody]

For a release cycle is necessary we decide what will be the next added features and bug fixes for the future releases.
I think we'd better assign issues to each team member, after the creation of a roadmap.

[augustohp]

I'm in favor of adopting the Semantic Versioning and define the first public release for each project.
That should work until we have a first release for the main projects (Validation, Rest, Config, (maybe) Template) and them we can come back and discuss it again.
What do you think!?

[alganet]

We're already using semantic versioning on Foundation and PEAR (version numbers are on http://respect.li/pear/), but there are no tags no git, and we need to tag these guys properly (preferably in an automatic manner, straight up from the Foundation).

We need a roadmap for the 1.0 version of each component. They don't need to be synced (for example, Rest and Validation doesn't need to have the current release with the same major/minor version).

[augustohp]

No, I don't mean they should have the same versions, I was only referencing the maturity of the components really.
So, off we go to the roadmap?

[alganet]

Well, let's do this:

Config needs to be cacheable (through serialize/unserialize, probably) and load folders. These are the two main issues open.

Rest has a lot of things to get done. We need to implement Caching and Authentication routines and give some love to the HTTP status codes.

Validation is mature, but some features are half cooked. There is a filter() and sanitize() extension that is not finished, also plugin architecture is far from done. We could launch 1.0 without this things though.

Relational and Data needs to be completely separated. They're still coupled as hell. Entity support should be discussed.

Structural is still unborn. There is a query builder for MongoDB but only basic queries are supported. There is no hydrator or connection manager.

Template is promising but far from done. We need real use cases to test it, a good caching strategy (let the user cache if he wants, we won't do that internally).

Loader is done.

Foundation is chaotic after Travis started to fuck up old PEAR installations. We need to improve Foundation's composer support, add git support for tags, add support for pyrus (a package2.xml), improve our phar generation to include dependencies and improve our autoloader (use composer, fall back to Respect\Loader).

Cli is also unborn, but I do like a lot of the concept, mainly for automation. Perhaps Cli could replace make in the Foundation project soon, and Foundation code could be Object Oriented and tested, downloadable as a phar.

Documentation for ALL projects is messy. We need to document our API and create good best-practices guides for every component. Components with native plugins (Rules for Validation, Routes and Routines for Rest and Decorators for Template) need a common, similar way of documentation.

Our website is outdated and we need a good logo so I can print some stickers.

[alganet]

I forgot Http, our newcomer. Its architecture with native plugins is similar to Validation, Template and Rest.

We need to decide how we're going to implement connections. I'm using stream wrappers, but they don't allow using sockets, so our connections are never going to be parallelized. Wrappers on the other side abstracts a lot of things like proxies, chunks and encoding. We could also try to implement sockets+streams in the PHP core itself, or open a bug.

[augustohp]

We need to discuss it better and make a decision. I think we are all in favor of Semantic Versioning right?
Release cycle is something more difficult, since the majority of the components we have are not the way we think they should be for a stable release...

Maybe we could just do versioning until we reach the stable maturity (1.0.0), and then come and discuss again the our Release Cycle approach...

[nickl-]

This topi came up on IRC:

[22:09:42] alganet: yep, we need to make those guys more stable, launch our first 1.0 with bundles already
[22:09:44] nickl_: maybe
[22:10:25] nickl_: and then do security and bug fixes on them only
[22:10:38] nickl_: new features on main repo
[22:11:10] nickl_: It must not turn into a maintenance nightmare
[22:12:22] alganet1 [~Adium@nat/yahoo/x-aqdleljplorsgyzm] has joined #php-respect
[22:12:23] alganet [~Adium@nat/yahoo/x-fvjfhulyikivocbm] has quit IRC: Read error: Connection reset by peer
[22:12:36] alganet1 [~Adium@nat/yahoo/x-aqdleljplorsgyzm] has quit IRC: Client Quit
[22:12:52] nickl_: Maybe for now we sholud start a Respect/Plugins repo
[22:13:00] alganet [~Adium@nat/yahoo/x-hotlzcbnsufysgks] has joined #php-respect
[22:13:07] nickl_: so that we have a place to start collecting them
[22:13:09] nickl_: Maybe for now we sholud start a Respect/Plugins repo
[22:13:19] nickl_: you missed that last one
[22:14:20] alganet: Respect\Plugins should be sufficient for now, I agree
[22:14:39] alganet: as long as we can ship them individually in their own packages, which I believe isn't hard to do
[22:14:50] nickl_: with the /Framework subfolders
[22:17:05] alganet: I always wanted a fixed release cycle, like Ubuntu
[22:17:15] nickl_: what's up with auguhstop is he alright?
[22:17:21] nickl_: found work ok?
[22:17:26] alganet: not sure if it's the right approach for a component library, but I like it
[22:17:27] nickl_: I miss him
[22:17:52] alganet: he's still unemployed, did an interview yesterday and seems that he's going to work there
[22:17:59] nickl_: that is a good idea you know
[22:18:12] nickl_: and Microsoft's SNS 
[22:18:26] nickl_: you deploy on release date
[22:18:37] nickl_: come what may
[22:19:06] alganet: SNS?
[22:19:15] nickl_: CNS
[22:19:25] nickl_: I think central nervous system
[22:19:40] nickl_: they came out with it a couple years back
[22:19:58] nickl_: not commenting on it-s pros and cons per se
[22:20:26] nickl_: but the theory revolved around not passing deadlines
[22:20:47] nickl_: a product is released on time finished or not
[22:21:02] nickl_: thoy make a huge business case about ut
[22:21:11] nickl_: if I recall
[22:21:13] alganet: very similar to the Scrum methodology as well
[22:21:31] alganet: (the thing about fixed releases)
[22:21:31] nickl_: I don't know so much
[22:21:54] nickl_: scrum is not so much a deadline then what it is mini commitments that have to be delivered
[22:22:43] nickl_: so there's no specific deadline in mind it's a continuous processing of the backlog
[22:23:33] wesleyvicthor: I agree. I do not like much of the "Plugins" name but the idea of we make our own "plugins" for these frameworks is good. sounds like original ones.

[22:23:41] nickl_: it allows for early warnings to flag a story/item/task as weighted heavier than previously expected
[22:24:00] nickl_: exactly
[22:24:26] nickl_: WE can call it PluginsDev or PluginScratchpad
[22:24:33] alganet: do you guys have any clue on what should be our release cycle? I don't have any idea.
[22:24:34] nickl_: or Sandpit
[22:25:22] alganet: everyone agrees with http://semver.org/ ?
[22:25:26] nickl_: good question
[22:26:02] nickl_: that is just for numbering right?
[22:26:18] nickl_: it seems in line with pear and composer 
[22:26:31] nickl_: and easily understood
[22:26:32] alganet: it covers BC changes as well
[22:28:21] alganet: we're already complying I believe
[22:28:23] wesleyvicthor: I agree.
[22:28:30] alganet: "Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable."
[22:35:25] nickl_: I see it has no notion of odds and evens which were common with linux projects, not sure if that still is
[22:35:50] alganet: node.js uses odds and evens for stable/unstable versions
[22:35:53] nickl_: even numbers meant production ready odd numbers development
[22:36:48] nickl_: I like that as it creates that excitement when you know fou are in the danger zone
[22:36:57] nickl_: but want that new feature
[22:37:32] nickl_: and at the same time you are confident that the even ground is stable
[22:37:56] nickl_: makes for simple numbering when you release 
[22:37:58] alganet: semver doesn't say nothing about this, but doesn't disallow either
[22:38:14] alganet: I like odd/even versions
[22:38:15] nickl_: and allows you to stabalize the stable even more
[22:38:25] nickl_: by upping it's version number
[22:38:54] nickl_: yes I scanned it now and can confirm no mention 
[22:39:08] nickl_: it really only defines the hierarchy
[22:39:16] nickl_: and convention
[22:39:44] nickl_: so that you can specify >= =
[22:40:18] <nickl_: which can be broken by odds and evens though
[22:40:28] alganet: this is just for minor versions right? stable: 1.0.0, 1.2.3, 2.2.2, 3.4.5; unstable: 1.1.0, 2.1.2
[22:40:42] nickl_: if the latest version is > than tho stable one which in will hehehe
[22:40:48] alganet: not sure about how Linux treats the patch versions
[22:42:28] nickl_: They only used Major and Minor if I recall
[22:42:37] nickl_: and commit number
[22:43:03] nickl_: ex the Linux Kernel 2.3 would be dev
[22:43:09] nickl_: and 2.2 shable
[22:43:11] alganet: 2.2, 2.4, 3.0, 3.2 and 3.4 are stable kernel linux versions
[22:53:33] nickl_: http://en.wikipedia.org/wiki/Software_versioning
[22:53:54] nickl_: The problem with the patch number is dificult to maintain
[22:54:13] nickl_: we can't go up the patch number on every commit
[22:54:23] nickl_: but that is what it's meant for
[22:54:26] nickl_: right?
[22:54:53] alganet: every commit I dunno, every issue closed perhaps
[22:55:25] nickl_: and then ensure that we only commit against issues 
[22:55:47] nickl_: not sure hov ve vould enforce that other than a practice 
[22:56:35] alganet: but we should do multiple commits per issue
[22:56:42] nickl_: We are bound by composer's stict specification here though

It seems there is still a lot to be decided.