New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release v4.22 #4197

Open
mojoaxel opened this Issue Nov 21, 2018 · 24 comments

Comments

Projects
None yet
@mojoaxel
Copy link
Member

mojoaxel commented Nov 21, 2018

I'm willing to create a new professional release "v4.22". But only if the OpenCollective Budget of vis.js allows for a spending of about 500€.

So if you want a new release please consider throwing a few πŸ’² in the 🎩
Thanks!

@mojoaxel mojoaxel added this to the Minor Release v4.22 milestone Nov 21, 2018

@knbknb

This comment has been minimized.

Copy link

knbknb commented Nov 21, 2018

What does that mean, a new professional release? Merging in all (at this time) 44 pull requests, resolving all 720 open issues? (Just joking). But does it mean, for instance, including most changes that are now in fork timeline-plus? Fixing those that are labelled "Fixed awaiting release" (n = 16 currently)?

I don't want to negotiate here; I think it's great that you started this initiative, and I'm suggesting just do what you think is most critical, or easiest, or most requested.

I just thought most people will ask themselves a similar question, (what does it mean?)

By the way, I'm indeed willing to spend a few Euros (say 15) of my own money.

@mojoaxel

This comment has been minimized.

Copy link
Member Author

mojoaxel commented Nov 21, 2018

@knbknb Thanks for your support!

I haven't looked into this for a long time but my main concern would be to release the current develop branch and merge it into master. The develop branch is way ahead at the moment (> 50 Pull-Requests merged).

This release will include things like this:

  • Short Review of all merged Pull-requests for breaking changes.
  • Creating an extensive release-note.
  • Publishing the release.
  • Updating docs and the website.
  • Closing Pull-Request, Milestones and such thing on github.
  • Going through the examples and creating new Bug-Issues.

This release will NOT include:

  • Commenting on issues.
  • Reviewing/Merging new Pull-requests.
  • Merging anything that is already released in timeline-plus.

To make that clear: Managing this project would be almost a full time job, especially if it should improve and be more manageable in the future. This only would be possible with a big sponsor!
Creating a new Release is the bare minimum at this moment!

So, if your company is using vis and is willing to sponsor future development please talk to me!

@jladbury

This comment has been minimized.

Copy link

jladbury commented Nov 22, 2018

It is very good news that this project could be actively maintained again. The crowd-funding approach seems a good one. However, before contributing, I would appreciate a bit more background about the project's relationship with timeline-plus. It would be a shame to see two divergent but basically similar projects.

@mojoaxel

This comment has been minimized.

Copy link
Member Author

mojoaxel commented Nov 22, 2018

I would appreciate a bit more background about the project's relationship with timeline-plus

The future goal for a long time has been to seperate vis into its different modules (#2405). This is a lot of work and only possible with a long-term sponsoring. Until then all pull-requests should be done to timeline-plus what I would consider the best version at this moment.

@YakovL

This comment has been minimized.

Copy link

YakovL commented Dec 4, 2018

Found this only accidentally, because of a new comment in another issue. May be a link to this deserves a spot on the main page here:

image

@saliez

This comment has been minimized.

Copy link

saliez commented Dec 11, 2018

Excellent idea to contribute to the maintenance of VIS.JS and I could contribute with the 500 €.
As a retired doctor I am very interested in experimental prototypes in order to handle medical knowledge in a very natural way based on graphs.
Therefore I need support on both "NEO4J" data base and "VIS.JS" visualiszation.
Have a look at http://www.chos-wg.org/Projects/IMMM/main-IMMM-Overview.html
and a very preliminary exercise is at:
" http://www.chos-wg.org/Projects/IMMM/IMMM-preliminary-prototype/immm.html ".
A new release of VIS.JS should be integrated in
NEOVIS, " https://github.com/neo4j-contrib/neovis.js ".
A working prototype in Open Source is necessary in order to discuss with medical colleagues across Internet.

@mojoaxel

This comment has been minimized.

Copy link
Member Author

mojoaxel commented Dec 11, 2018

A new release of VIS.JS should be integrated in NEOVIS

@saliez Please create an issue over at neovis if you want them to update vis.js.

@avrahamcool

This comment has been minimized.

Copy link

avrahamcool commented Dec 26, 2018

@mojoaxel first of all, thank you for all the work you done this far on this greate project.
I've donated 50$, and hopefully more of us will invest in the OpenCollective.

keep us updated :)

@exoego

This comment has been minimized.

Copy link

exoego commented Jan 8, 2019

@mojoaxel, other maintainers and contributors

I would like to express deepest gratitude on behalf of Kurusugawa Computer Inc..
We are relying on vis in the past few years and just have donated $400 to vis.js via OpenColletive.
We are looking forward to an advance in vis development.

@mojoaxel

This comment has been minimized.

Copy link
Member Author

mojoaxel commented Jan 8, 2019

We are looking forward to an advance in vis development.

πŸŽ‰ Thanks so much!
I'm looking into building a release early 2019. I'm currently very occupied but I try to build a release in the next weeks.

@mojoaxel

This comment has been minimized.

Copy link
Member Author

mojoaxel commented Jan 9, 2019

Hey everybody!

It would help if some of you could go through the pull-requests and review them!
For simple changes it is enough to look at the code and make sure coding standards were respected and that the changes make sense. For more complex changes the PR must be checked out, compiles and tested thoroughly.

This is a lot of work and it would be wonderful If some of you could find the time to help out. It is so sad to see so many pull-requests unmerged!

@knbknb

This comment has been minimized.

Copy link

knbknb commented Jan 9, 2019

This is a lot of work and it would be wonderful If some of you could find the time to help out. It is so sad to see so many pull-requests unmerged!

This should be done on the develop branch, if I remember correctly a thread from a few days ago?

@YakovL

This comment has been minimized.

Copy link

YakovL commented Jan 9, 2019

It would help if some of you could go through the pull-requests and review them!

so what's the procedure? If I review a PR, should I just leave a comment that it's ok (and may be annotate it a bit) or something different?

@mojoaxel

This comment has been minimized.

Copy link
Member Author

mojoaxel commented Jan 9, 2019

This should be done on the develop branch

Yes, all PRs should be done to the develop branch (for now).

so what's the procedure? If I review a PR, should I just leave a comment that it's ok (and may be annotate it a bit) or something different?

There is a green review button in the top right corner of each PR.
see https://help.github.com/articles/about-pull-request-reviews/

@Jogai

This comment has been minimized.

Copy link

Jogai commented Jan 9, 2019

Some are labeled "timeline-plus APPLIED" by @yotamberk so I think those are good enough to merge.

@mosaikly

This comment has been minimized.

Copy link

mosaikly commented Jan 15, 2019

We donated for thank's your work.

@mojoaxel mojoaxel self-assigned this Jan 30, 2019

@Jogai

This comment has been minimized.

Copy link

Jogai commented Feb 5, 2019

Some are labeled "timeline-plus APPLIED" by @yotamberk so I think those are good enough to merge.

Oh, I see now that you wont include "Merging anything that is already released in timeline-plus.", but why? Arent these the things that are the most reliable since its incorporated in the fork already?

@yotamberk

This comment has been minimized.

Copy link
Contributor

yotamberk commented Feb 5, 2019

No quite. The PRs applied in my fork have been fixed or reviewed when the PRs we're not perfect. Accepting these PRs is not reliable.
If you want a reliable timeline, use mine.

@Jogai

This comment has been minimized.

Copy link

Jogai commented Feb 5, 2019

Why not merge it back to this project then? (Also its hard to see because its not forked trough git it seems).

@avrahamcool

This comment has been minimized.

Copy link

avrahamcool commented Feb 5, 2019

it's not an easy merge - because the names of all objects are different.

@jgorene

This comment has been minimized.

Copy link
Member

jgorene commented Feb 14, 2019

Simple question from a newbie about this matter (I think for a while yet)

The v4.22 will be released by a simple update directly from the develop branch ?

Or from master branch, keeping only what works fine and adding approved PR ?

I am asking this question particularly for graph2d module where there are still some problems in develop branch (among others but not least)
Always from this branch , I tried to fix some things but whithout success !
It's still a huge cake for me, sorry πŸ˜”

Thanks a lot (again) to all who maintain... πŸ‘

@mojoaxel

This comment has been minimized.

Copy link
Member Author

mojoaxel commented Feb 14, 2019

The v4.22 will be released by a simple update directly from the develop branch ?

The release process is quite complex (see e.g. #3076).
During the release process the develop-branch is merged in to master.

It look like the 4.22 release will be very special because if propably will be the last release 😒
All existing bugs and feature requests will have to be fixed in a new project. More infos about the future of this project will follow soon...

@jgorene

This comment has been minimized.

Copy link
Member

jgorene commented Feb 14, 2019

@mojoaxel I wasn't even going to try, just I wondering ...
Otherwise, sure it's too bad that it stops πŸ’”
If it allows to make this library evolve by restructuring it, as already suggested by some guys here or why not reborn in another format at the end,.. you never know;)

@mojoaxel

This comment has been minimized.

Copy link
Member Author

mojoaxel commented Feb 14, 2019

If it allows to make this library evolve by restructuring it, as already suggested by some guys here

My plan ist to split up the sources into multible projects (#2405) and give them a new live in a opensource vis.js community.

The best way at the moment is to seriously build, test and review pull-requests. I plan to merge as much pull-requests as possible but I also don't want to reduce quality.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment