I was inspired by development tools, especially version control systems (svn back in the day), issue tracking systems (jira in particular), continuous integration tools (cruisecontrol), build management tools (ant, maven, etc). I wanted to understand how to properly generate version numbers using algorithms and automation, especially for continuous integration builds. Also I wanted to understand how to effectively manage branches and their types, parallel development, maturity levels, incompatible lines of development and tags together with immutable artifacts.

What it does

It generates version number based on current development history for branches, tags and continuous integration builds taking into account branch types, incompatible changes, immutability of resulting artifacts and maturity levels. Operates on simplest text as a versioned entity.

How I built it

First generated high-level design with the drawing that described relationships between branch types, tag types, maturity levels, incompatible changes and version numbers. Based on that developed training to explain principles of version control, build management, continuous integration, merge management and agile software configuration management. As a part of the training, came up with approach for version numbering of continuous integration builds and restrictions for branch management. After that prepared a detailed specification where inferred specific metrics proving effectiveness of approach. Started with development of domain-specific language for software configuration management using Haskell. After several iterations built the tool using plain Haskell as a proof of concept. Created landing page that describes the principle behind the tool using data generated with the tool, explains the problem, solution, target audience and unique value. Came up with standalone web-based visualization module using D3 framework.

Challenges I ran into

Insurmountable resistance towards accepting the problem and suggested solution. Was not able to run a survey that proves the problem exists. It took a long time to build it and to explain its value. Nobody wanted to help with building it. Misunderstanding, isolation, despair, long periods when I could not work on it. Didn't want to continue, dropped work and switched to something else many times. Could not integrate visualization module with back-end. Could not resolve bugs in visualization engine or rewrite it in Elm. Accumulated technical debt.

Accomplishments that I'm proud of

Award for best graduate work award among Computer Science department graduates of 2009 at my university for thesis on tools and methods for software configuration management. Developed and conducted offline and online training about software configuration management. Getting next to perfect understanding from several students that took my training. Two confirmations from fellow research students that it makes sense after long personal discussion sessions. I overcame all challenges on the way to actual working tool that demonstrates proof of concept for version numbering. Learned and applied the most advanced programming language that is currently available. Built proof of concept for streamlines visualization for version numbering, branches and tags.

What I learned

I learned how to give up to continue working, how elegantly Haskell implements main principles of the tool, how to explain complex things, how to build something unique that wasn't done ever before, how to stand behind my idea, how to achieve more with less, how to attract target audience and investors, how to explain value of the idea, how to build custom visualization engine with D3 visualization framework, presentation skills, training development skills and learning performance assessment skills.

What's next for VersioningRight

Integration with filesystem, version control systems (git first, then svn), continuous integration tool, visualization module, existing development tools (jira, confluence, bitbucket, fisheye/crucible, bamboo). Development of merge management module, dependencies management functionality, incompatibility detection functionality, common web-interface for SaaS solution. Finding first adopters, development of monetization strategy, testing minimum viable product and rolling out the production version. Getting to the point of using the tool for all the aspects of its own development. Adding artificial intelligence engine to give tips and guidance on how to develop solutions more effectively and with highest possible quality.

C19 challenge and sustainability development goals

VersioningRight helps to effectively develop technical solutions for wide range of the problems, but it is the most effective for development of solutions for most pressing challenges, such as, for example, C19. It helps to reduce waste in terms of lost effort spent on unnecessary development or tasks that are meaningless, impossible or derailing progress. Also it helps to optimize effort in order to make development more effective.

Built With

Share this project:


posted an update

I am a lead of the project to build a product for improving development experience and productivity. I need help from mentor. I have been working on this for 11 years almost completely ignoring what people actually want. All validation attempts failed and I built a demo of the tool myself based on research and my gut feeling without actually listening to anyone. 100% case of solutionizm problem. How do I validate the problem to find out what people actually need? How could I provide value throwing away everything that I have done to make steps towards the people who will actually use it? How to give up on something that I hold onto very fondly? How do I make complex stuff simple? How do I persuade people that I need their help and they need mine? I need your feedback.

Log in or sign up for Devpost to join the conversation.