master should become v0.10 branch

[lowagner]

master should track along with development, just for ease of developing...

i suppose that means renaming the current master to v0.1, and renaming v0.2 to master. (then splitting v0.2 off when a new version arises?)

(should v0.8 then be renamed to v0.08?)

thoughts?

[makapuf]

good for me, but I didn't want master to be unusable. it's becoming to be ok, I just want to try working on usb. So it's a branch until I fix/validate 8bit behaviour/ basic libs. Maybe we can have v0.8 still being v0.8, current being v0.9 and current v0.2 becoming v0.10 (would avoid renaming past things)

[lowagner]

ok, fine by me. i'll see how to unmerge your commit on greeble until the new kernel becomes useable...

[makapuf]

On 16bit kernel it's definitely usable.

[makapuf]

0.2 renamed to v0.10

[makapuf]

If you're on 16bits it's OK.

Le 22 oct. 2016 19:14, "Lucas O. Wagner" notifications@github.com a écrit :

ok, fine by me. i'll see how to unmerge your commit on greeble until the new kernel becomes useable...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/makapuf/bitbox/issues/76#issuecomment-255541092, or mute the thread https://github.com/notifications/unsubscribe-auth/AAlRERJNYqnHS4limZkoDbuBfDVblMkcks5q2kRngaJpZM4Kd3H2 .

[lowagner]

do you mean the bitbox macro (as opposed to micro)? 16bit color i guess...

still would like 0.10 to become "master", so that master tracks along with development (and eventually 0.10 splits off when we complete all milestones for 0.10)...

i think you could do that by creating the 0.9 branch from master, then merging your 0.10 into master (though there may be some conflicts), and later we can split off a 0.10 when we start going beyond 0.10...

[makapuf]

sure, I just would like to finalize things a bit in the next few days. wouldn't using submodule for games be a good idea to have a fixed kernel version ? (yes, 16bit is "macro")

[pulkomandy]

Yes, games can import a specific version of the kernel as a submodule. I think this makes sense: any kernel update needs to be tested with each game, and when things are ok, it can be updated.

[makapuf]

only issue is that the current kernel has many libraries (ok) and examples, bootloaders, scripts ... Should we really duplicate all of this in a /kernel subdirectory ?

[lowagner]

sorry to bother, how is the micro lib coming along? will we be able to set master->0.9, and merge 0.10 -> master soon? or were you going to split the kernel off into its own repository (to become a submodule in other projects), and just keep examples in this repository?

[makapuf]

Well, I think the interface changes are almost over. I'm thinking about a bit more but they can be pushed to a v.11, it's not a big deal.

[makapuf]

Closed with commit a62946dd

[pulkomandy]

It would be nice to have a "release" of 0.9 for future reference?

[makapuf]

Sure, what kind of release are you thinking about ?