Stable, WRC & WiPS

[cavearr]

Hello everyone, I wanted to propose a new package scheme to see what you think.

My idea is to continue working on the wips as a "rolling release" version. Yosys works like this and I like it a lot.

The concept is that it is a "live" version, a set of binaries would be generated every night, for example at 00:00:00 with whatever is in the repository that day, the version could work or not, have more or less bugs. In this way, testers or users who want to collaborate with the tests will have to test and give feedback on the binaries with the previous day's progress every day.

With the level of changes that we are going to make these months, the wip is going to be broken at many times, that is why I propose a new "line", the WRC (Wip release candidate), these WRC will be generated monthly, these wips should be quite stable and robust, they should allow you to work great.

The objective of these WRCs is to provide a version of advanced improvements to users that are stable.

As the WRCs will be used by users throughout the month, when we see that some features that we like and are stable have been achieved, we can propose at any time of the year, moving the corresponding WRC to a stable Release (in this way I think there would be more guarantees of releasing a couple of stable versions per year with stability guarantees).

My idea of ​​the WRC would also be to take a dictionary of plants, stars, movie characters or whatever you want and randomly each month the WRC will take a name. This way it would be easier to follow up.
It will be easier to identify the Mozart wip than the 13.3.43l30342034223930943029423

In this way we would have three possible binaries:

1. Stable, it should be robust and highly tested, right now it is not like that since the release processes until now have been chaotic and without too many tests or limited to a short time. With this new idea, when a WRC freezes it will have been in use for at least a month and to exit it should practically have had 0 bugs reported.

2. WRC, robust and with the latest improvements a month late, recommended for users who want to enjoy the latest features but do not want to have as many headaches as daily WIPS, frozen code from the previous month. Objective to report feedback.

3. WIPS, binaries with daily changes, unstable, recommended for developers and testers.

If we move forward, I will create some tasks in case some of you are interested in helping me with the automation of all this (if anyone is interested, I will give them a hand).

How do you see it, suggestions, should we move forward?

@lmcapacho @Democrito @jojo535275 @Obijuan @TimRudy

[lmcapacho]

Hi @cavearr !

This idea is amazing. I think it is very necessary for users to work with WRC versions before the release candidate version. On the other hand, as you mentioned, we could have a release candidate version with zero reported bugs.

I’m interested in helping with the tasks related to this idea. I’m on board.

[cavearr]

i'm count with you @lmcapacho ! give a couple of days at this thread for more ideas, and we could start to defining tasks. I like to change the current version changes windows that now has no sense, i want to improve the method in the way that each WRC had a video or videos in this window with the features in action , to show the user , how could find in it.

In short i propose you in a new discussion a new window for this (for wips with the list of changes in course and for WRCs, more detailed page), this will be an easy task but very needed for one that could take it. I want use this easy devel task to do a tutorial for the icestudio plugin system, i'll evolve it in short but is needed that all of you know how it works to implement the next pieces well together.

Thanks again!! team!

[jojo535275]

Hello guys,

For me, the 2 versions (stable + wips) strategy was simpler !
And the choice, for the users on the icestudio download page was simple too!
Of course it can be improved for example, as Carlos mentioned , improving the information about the changes/new features!

But if you guys see advantages on this new strategy (with 3 running versions), no problem for me! i will get used to it ;-)!
I also hope that these "fixed" timings constrains (daily wips/monthly releases ) will not induce any kind of additional pressure on the developers ;-) !

Big hug!

[cavearr]

Hi @jojo535275 ! really is important to have the three, now the changes in wips should be very constant and many times we could produce wips that not works well (at Yosys if you use the upstream many more times, are broken in some place for example).

I think there are a lot of users that there haven't any interest in development stuff but wants to use the latest features/improvements. For this users are the WRC (and we have lot of them).

The daily releases not imply work for us, we could schedule a github action for every night and automatically every day we have a "nightly or wip daily" verions at https://downloads.icestudio.io

The WRC is very necessary if we want to do better our current release process. We must lovingly package this pre-release every month, which will not only allow users to enjoy a powerful and current icestudio continuously, but will also allow us to consolidate with time and guarantees a solid version to release a couple of stable ones a year with methodology.

I think this is going to give us much more strength as a team and a better relationship with users.

[TimRudy]

Hi all -

I was thinking exactly those sentiments, and wanted to agree: Very necessary, ... Project can be better in release process.
3-tier basically aligns with software and open source release practices - but I want to give my reassuring perspective also to JoMo, below :-)

Problem:

• The WIP became the de facto release. "Stable" version is actually outdated, sometimes it's not appropriate (to point the user to it!) because it hasn't kept up with bleeding-edge, cool tech that the community is talking about.
• Another part of Problem that is actually part of Solution is: oss-cad-suite and yosys, those things go into Apio in a more continuous way now with whatever wizardly our team (Carlos, Obijan) has put into that - I haven't followed that too much but let's trust them: it's automated, sexy, so: all the capabilities and bug fixes align much quicker these days.
• So, with the WIP problem, Carlos is stuck with issues or messages coming in saying that it's broken - but of course it's broken, it has to be "exercised" a bit.
• The close team of collaborators who are testing the latest and making contributions should not overlap with the large main public community. This is an important issue: the perceived quality, the reputational risk for Icestudio. I know it's the case that the large community is pretty technical and forgiving, but Icestudio is competing dog-eat-dog out there... This initiative will stop it from seeming like a quirky (informal?) tool - one where the "user base" is waiting for a quality release that never arrives.

Solution:

• The initiative is enabled exactly by current automated pipeline and continuous deployment. Go build and release! The motto, I could gently suggest, could be: "Lovingly yet Automated"!
• I hope it's helpful to think of this:
  a) WRC is, if I'm not mistaken, the main artifact that would normally be "pointed to" in discussions on the community group; sure, it's a little oriented toward the "technically inclined" or the "preview" users, but who isn't? So there's not much of a change in that sense - psychologically or practically - right? Just new link and new terminology.
  b) Stable is there because of "good form", being a good citizen - enough said - it's available - and I think probably it will be released more often now.
  c) The "third layer" is a hidden layer, please do not talk about it in public. I.e. the Nightly, or WIP, is opt-in, it's only for the truly inside masochists and helpers who have shown their love for the FPGA, and other electronic components and techniques such as VGA, signed arithmetic, lookup tables.

Result:

• Message to the community of the change in direction. Convenient download link. No more relying on Nightly.
• When users (in FPGAwars/Libre community, or in wide public) download a version, they know exactly what to expect.
• (Side effect: You may ask me to help with automation, or documenting... and that's good, I want to help. Cheers)

[jojo535275]

Ok , buddys let's go !! 👍

[cavearr]

Thank you very much, @TimRudy , for your extensive and incredibly interesting feedback.

First of all, I totally agree with EVERYTHING.

Secondly, perhaps I did not explain myself well regarding the division of releases. There is a very, very important change, not just in terminology. I will try to explain myself better:

We need a Stable version. It is not my preferred option, but several universities worldwide and quite a few highschools use Icestudio. This is a version I have "stepped aside" from because it has mainly been used by Obijuan for his university classes, and he has aligned its development with his needs. Over time, I have personally come into contact with other universities, and they have communicated their needs directly to me. The main reason for having a "Stable" version is that in these institutions, where Icestudio is a crucial part of training future engineers and STEM-focused students, they cannot keep reinstalling the software repeatedly. They generally set up the lab once a year. Therefore, I believe that having one or two stable versions per year should be more than sufficient. We should aim to release one version before the summer since these labs usually reinstall during the summer break. (We could even opt for just one stable release per year around May-June to avoid overloading ourselves for now.) Maybe we could rename this version like "Education edition" or something like that.

In my view, the Stable version should directly derive from the current release candidate (WRC). At the time of release, we could remove any features that are not well-tested. Ideally, it should consolidate everything that has been running for at least two months. The goal is to avoid chaotic and rushed testing of the release and instead focus on stabilization and packaging.

The objective of this release is to be distributed as binaries.

Then we move on to the WRC. This is not the same concept as the current WIPs. The WRC should contain all stabilized changes and improvements from the previous month. In my opinion, this should be the default binary distribution for all users. Maybe we could rename as "upstream" or some fancy name that not generate terror in the users.

One of the next tasks I am about to present, which is almost finished, is a package manager—similar to the "Apple Store"—that will allow users to install collections and… UPDATE ICESTUDIO 😄

The idea is that a regular user would download the WRC and then update it monthly if they wish. The WRC should be robust enough that nothing critical breaks at first use.

Then we have the WIP/nightly builds (or whatever we want to call them). These binaries would be strictly for testers who are not developers. We have valuable testers, like @Democrito, who does not have a technical programming skills but rigorously tests every binary that we release with incredible feedback. These versions should only be used by these users who want to collaborate in the development and QA of Icestudio. The reason for generating them automatically every day is to streamline the process so that there is always a version available for testing (even if some days no one tests it because there are no updates or no testers available). If we go ahead, we need to stablish a protocol to annonunce, report bugs.....

Regarding Apio, @zapta has been doing an incredible job this year. My confidence in Apio has grown significantly since @zapta joined the team. Additionally, I am working on some very important improvements in Icestudio to enable direct use of Yosys commands (via Apio to simplify management). This will help improve board integration formats and ensure everything is more consolidated and unified.

Along these lines, I want to develop our system-tools to maintain a rolling release version aligned with Yosys, allowing users to always access the latest Yosys version (I need to discuss this further with @zapta).

Overall, the idea is to simplify processes as much as possible, making everything easier and ultimately achieving a killer version of Icestudio.

I am preparing my roadmap to share with you. My goal is to make my thoughts transparent, collaborate with you, and create an incredible tool together. The first experiment of sharing an idea (the code block) was very well received, and I believe it will help us all feel like part of this exciting project.

I am also working on a new website with a strong focus on documentation. This is another key aspect that I am very eager to get right. I hope to count on all of you for this. My goal is to create a very interesting community space where we can share progress and explore possibilities together.

This year is crucial for the project. I am making a full commitment to ensuring its success—both technically and organizationally—investing my time and resources beyond just a hobby. We will gradually refine the system, and I am confident it will experience a quantum leap. ;)

I need time to put everything into motion, organize ourselves, delegate tasks, and ultimately drive the project forward with solid foundations. I do not want to repeat past mistakes—I want each step to be fully consolidated. There is a lot to do and there are very few of us but I am sure we will make it, the rocket is taking off...

Thank you to the entire team for sharing, collaborating, and pushing this amazing project forward. Love you all! ❤️

[zapta]

Hi @cavearr, a few random thoughts

1. Having a wip that is built every day or week will be very useful.

2. I think that flowers/stars/composers will add unnecessary complexity and confusion compare to straight dates, as Yosys does.

3. How do you plan to have the two or three lines of releases you plan, will you have a repo for each one? Can you have multiple lines of releases in the same repo?

4. Regarding apio, we can and should do the same, once we switch from 'pip install' to actual packages. I hope to get your help in setting up the apio signing and distribution.

5. It's possible that two lines of releases are sufficient, stable and WIP. Having a third one of 'somewhat stable' may be confusing.

[TimRudy]

I feel it's an important point that the third level, the nightly release, is not visible, it's exclusive, it's not really discussed except among Carlos and collaborators - Is that correct?