moving future branch to master branch

[justinmeza]

RFC: let's promote the future branch to master

Some background

When I started lci, my goal was to implement the full 1.2 LOLCODE specification as accurately as possible. That version of lci is ultimately what resides on the master branch right now.

Realizing some of the limitations of the 1.2 spec – but without a formal 1.3 spec – others and I started working on implementing and experimenting with new features (like BUKKITs and so on) on the future branch.

The problem

Right now the master branch is in maintenance mode and only gets updated when bugs are fixed. On the other hand, the future branch sees more active development. It's not a ton of development :) but it's some. And besides, the future branch has some of the more interesting features including BUKKITs, file I/O, and network sockets.

The proposal

The proposal is simple: I'd like to promote the future branch to be the master branch. At the same time, I'd move the current master branch to be called the 1.2-spec branch.

This will make it a lot easier for newcomers to discover the most feature-rich version of lci.

Potential downsides

Note that the current implementation in the future branch has several changes that break compatibility with LOLCODE 1.2. This has allowed us to greatly simplify the code.

Also, there is not published specification for how the current future branch behaves. I will try and publish a 1.4 spec on the lolcode-spec project. (Note that I'm skipping 1.3 to avoid confusion with the proposed 1.3 specs that can be found on archives of the old lolcode.com site.)

Summary

Aside from the branch name change, there won't be much of a noticeable difference. Let me know if you have any thoughts. After a while, if there are no burning issues, I'll make the change.

😸

[jasonhemann]

Would moving future to master close out #38 ?

Edit: It seems not, at present. But it would be nice to know if future will address #38 or if the behavior is correct as is.

[leyarotheconquerer]

As a small note, future is incompatible with Windows MinGW builds because it relies on Readline and the Linux Sockets libraries.

I've tried building using replacements like linenoise and winsock2, but the changes are non-trivial and would probably break the Linux builds.

Of course, Windows 10 now provides the WSL, so running the future branch on newer versions of Windows is now fairly easy. But migrating to the future branch right now would mean confining lci to Linux systems like MSYS and Cygwin for older versions of Windows.

Just some food for thought from a Windows user.

[aurasphere]

@leyarotheconquerer I don't think this is a small note! This should be documented properly... I've spent hours trying to build the lci on MinGW without success... I'll try building it on Windows 10 and see if that works, thanks!

EDIT: Yes, I can confirm that the build works on Windows 10 WSL.