Roadmap Discussion

[silverhook]

In #173 we have decided that releasing 2.0 should be released as soon as possible.

I suggest that we go through the list of issues and pull requests and tag all that we think must be in 2.0 with Elegant 2.0.

Currently the description for the 2.0 milestone reads:

All those fixes and features that do not require creating Pelican plugins or changes in Pelican code. This release will have updated and additional documentation too.

… which I think still holds true (if a bit vague), but if someone has a better suggestion, do share.

The bigger problem is the intended release date (2014-01-26).

I suggest we aim for 2019-01-26 for the 2.0.0 – that sounds doable.

I also created Elegant 3.0 as a milestone with the main goal as removing Bootstrap as a dependency, to make it easier to maintain in the future.

Also, I thought it would be a good goal to state that 3.0.0 should have feature parity with 2.0.0.

Personally, I would say:

1. for 2.0, we should now merge all requests and fix all issues that don’t break anything and are easy enough to implement.
2. after 2.0.0 is out, we should concentrate on 3.0 and get rid of Bootstrap
3. after 2.0.0 is out, it should be in maintenance-mode and we should work only on ironing out serious bugs; new features to 2.0 should only be admissible along with a pull request, otherwise we’ll leave them for 3.x (3.1 or later)

---

All of the above is just an initial suggestion and up for debate – which this issue is intended for.

So, please, share your thoughts on what 2.0 and 3.0 (and perhaps 2.1) should look like.

[talha131]

Why don't we use Github kanban board for displaying the roadmap?

[AWegnerGitHub]

Where do we want to fit support for Pelican 4.x? I tested it and there are a few warnings/errors that appear. I don't have that full list available right now. I need to build a clean environment and regenerate everything (I'm trying to pull my personal changes out and submit pull requests)

[talha131]

I think after releasing 2.0, a minor 2.1 release can be made that add support for Pelican 4.x.

Coupling Pelican 4 support with bootstrap removal would be a bad idea, as we have decided, on another thread, to release early and often.

[silverhook]

I think after releasing 2.0, a minor 2.1 release can be made that add support for Pelican 4.x.

Coupling Pelican 4 support with bootstrap removal would be a bad idea, as we have decided, on another thread, to release early and often.

I think this is a very good suggestion!

To summarise:

• 2.0 for wrapping up our backlog and making sure things work on Pelican 3.x
• 2.1 for making sure all is fine with Pelican 4.x
• 3.0 for removing Bootstrap

[talha131]

Now that I think about it, 3.0 can be broken down into several minor releases. For example,

1. 3.1: Remove bootstrap accordion. Use pure CSS accordian
2. 3.2: Remove jquery for filtering tags page. Use pure JS
3. 3.3: Migrate typography from bootstrap to our own css file
4. 3.4: Remove Boootstrap grids. Use CSS grid or flexbox
5. 3.5: Remove bootstrap top menu bar
6. and so on.

Somewhere in between, we may add PostCSS or SCSS support, and support for visual regression testing.

[silverhook]

Now that I think about it, 3.0 can be broken down into several minor releases. For example, […]

That might be a more rewarding way forward, yes. This means we could have 4.0 as a clean version to start from.

[talha131]

@silverhook just so you know, I have added a Kanban board for 3.0

https://github.com/Pelican-Elegant/elegant/projects/1?add_cards_query=is%3Aopen

Later when we actually start working on 3.0, we can convert these cards to issues and add them to release milestones.

[talha131]

@silverhook There was only one issue left in Milestone 2.0, which was related to documentation.

I transferred the issue to the documentation repo. You can view it here.

https://github.com/Pelican-Elegant/documentation/issues/21

Now all the issues in milestone 2.0 are closed.

https://github.com/Pelican-Elegant/elegant/milestones/Elegant%202.0

When feasible, can you please triage the open issues and PR that think should go into 2.0 and assign them 2.0 milestone?

[silverhook]

@talha131: Will do.

[talha131]

To all contributors to this thread and @calfzhou, @iranzo

We now have separate milestones for releases in near future.

https://github.com/Pelican-Elegant/elegant/milestones

We have branches for 2.1 and 3.0

https://github.com/Pelican-Elegant/elegant/branches

If there is any change that should not go into master, then please open PR against the appropriate branch. For example, you can see that @iranzo PR related to Pelican 4.0 is merged only in dev-2.1 branch.

https://github.com/Pelican-Elegant/elegant/commits/dev-2.1

Finally, I have added all the issues and PR that we must fix before releasing 2.0 into 2.0 milestone.

https://github.com/Pelican-Elegant/elegant/milestone/3

There are other PRs and issues, but we can triage them in next release.

So please you are more than welcome to pick up unassigned issues from the milestone.

PS: If you disagree with the issue selection or think I have missed some showstopper, then please feel free to voice your suggestions. It's after all a community driven project.

[talha131]

Guys https://github.com/Pelican-Elegant/elegant/milestone/4 is open and we have a branch for it. Please feel free to pick issues from it and start resolving them.

We are almost done with https://github.com/Pelican-Elegant/elegant/milestone/3

Lets keep the momentum going.

[talha131]

Guys 2.0 is almost ready. We just need an announcement article. https://github.com/Pelican-Elegant/documentation/issues/52

Is anyone willing to take this issue?

[iranzo]

I was wondering if we should default 'devel' to master to simplify the backporting process. I'm using on my site 'next' branch as I do wanted to have the fix for RSS that made publish to fail but by using it, I'm lacking lot of features that are available on master.

I saw other themes and they default to one branch (master) for regular updates and use case, and probably spin-off for other changes like the bootstrap changes we've discussed in the past.

(just to start conversation)

[talha131]

I'm lacking lot of features that are available on master.

I see your point. We would not be having this issue,

1. If we release 2.0 ASAP (I am talking about days, not weeks)
2. Ask all future contributions to be against 2.1 or next branch.

The dev and master branch model was adopted to release 2.0 as early as possible. But we clearly have failed in this regard.

I suggest, we release 2.0 soon and create a next branch. All future PR should be against next (unless necessary).

[iranzo]

+1 on 2.0 soon :-)

[talha131]

@silverhook we are tracking the roadmap using milestones. I think we can close this issue now.

[silverhook]

Agreed