Steps forward

[pythoneer]

To reiterate over the last attempt and repeat what my main problem was:

It is hard to see what actionable tasks are "laying around". I think a good way to move forward could be to go over the current open issues and maybe try to categorize/label them. I would also want to see some milestones and or a rough way the project is going. Said milestones could be a way but i don't know for sure. I am still not very familiar with the codebase beyond the "entry level" Api surface. Especially after the v2.0 refactor. I think the documentation could use some work, that could be something where i can start right now. What other aspects should be included?

What is the preferred way of communication? I am watching the issues here, the gitter channel and i think i am getting notified on the contributors team page here on github. It would be cool to have a somewhat "regular" way to updates ourselfs on topics that need to be done and/or what we want to see in the future as features/improvements.

[JohnTitor]

Labeling and setting milestones seem reasonable (@robjtede has been labeling some issues/PRs, thanks!).
Also, I created a rough milestone (https://github.com/actix/actix-web/milestone/6).

We have two documentation, https://docs.rs/actix-web/2.0.0/actix_web/, and https://actix.rs. Not all of them reflect the current(v2) behavior so we should update them (opened actix/actix-website#145). If you find an incorrect explanation or something in actix-web's doc comment, please open an issue/PR here.

I'd like to discuss in public space such as issue tracker as possible since I feel it's important to have transparency in discussions and decisions.

[pythoneer]

Something that came to my mind is if we need to have something like active developed versions or the other way around deprecated/eol versions. I looked a little bit trough some projects on github that are using actix-web and you can see quite some old versions being use. Can't tell how "active" those projects are but many use v0.7/v0.6 and a few v0.5 etc. I think it would be better if we have something that would tell the user that those versions are EOL or something like that. I am not particular sure with v1.0 – do we consider this in "maintenance" mode so we try to eliminate bugs and try to think about back porting fixes from v2.0 but its not in "active development" mode? So as a general rule, we "maintain" one major version down from the current – something along the line.

And on this matter, we could introduce labels (v0.7, v1.0, v2.0 ... etc) for the various issues. This would help with closing "old" issues for versions that are no longer actionable because the affected version is not "maintained" any more. The problem i see with this is that this could get pretty convoluted because most of the issues would be on the current version anyways and in that case there is not much value to it. Just an idea.

What are your thoughts about that?

[robjtede]

+1 on the version labels, i've created them

[robjtede]

We should dicuss what is considered end of life for sure. My thoughts are we should backport bug fixes only for previous (-1) major version and not support anything older than that.

That might be too aggressive so open to suggestions. Are the reasons currently to support the v0.x branch?

[awulkan]

I think there shouldn't be too much effort being put into maintaining old versions right now. If you are going to do it later on, then you should probably decide which versions you consider stable enough to actually maintain for a longer period. There's no point in supporting an older version that might not be at a stage where it's worth making it an LTS version, if you get what I'm saying.

Most big frameworks that I've used choose their LTS versions very carefully to avoid having to do much work on them. With months of just bug fixing, without any new features, leading up to the LTS release.

It also depends on how often you plan on releasing a new major version. For example, .NET Core is set to release one major version per year, with an LTS every other year. But for a smaller framework like Actix I think it might be hard to plan things this well. Major releases tend to be more sporadic.

I think the most important thing is to provide a clear upgrade path between major versions. Not necessarily to maintain and backport new features and bug fixes to older versions.

[naturallymitchell]

This issue could be a 'landmark' (using semantic issue labels) for 'plans' and 'changes' coming up. So, the issues that reference it can be seen as having higher 'weight'.
+++

Also, let's use a Discord server for Actix Web #1545 to talk about this and other important things.