Re: [ANNOUNCE] Upcoming ISAR release

["Maxim Yu. Osipov" <mosipov@ilbers.de>]

Hi Claudius,

Thanks for the feedback.

OK, let's focus for v0.7 release for now.

On 2/18/19 10:58 AM, Claudius Heine wrote:
> Hi Maxim,
> 
> On 18/02/2019 10.01, Maxim Yu. Osipov wrote:
>> Hello everybody,
>>
>> Last release (v0.6) was made on 1st of October 2018.
>>
>> We plan to release the next version of ISAR on 1st of March, 2019.
>>
>> BTW, what do you think about making a 1.0 release?
> 
> IMO we need a lot more cleanup stuff before we can do a solid 1.0 release.
> 
> We should make a list of issues that should be done before 1.0 release.
> 
> Here is a suggested checklist before 1.0:
> 
>   - Remove jessie support

That's a point which I don't understand - yes, we don't support jessie 
as a host system, but why don't continue to support jessie based targets 
if this doesn't require big efforts? Industrial programming is very 
conservative in this point (that's why all these 
https://www.cip-project.org/ serve for).

>   - Improve documentation
>   - Cleanup the user interface variables
>     - Consistent variable nameing style

naming ;)

>     - Use feature variables instead of many VAR="1" ones. They can be 
> more easily bundled together in code and docs.

I vaguely remember this discussion.
Could you please provide arguments why we will benefit from that?


>   - Consistent and clear naming of things
>     - Build, host, target in line with GCC and Debian definition

Could this renaming confuse current Isar users?

>     - meta, meta-isar -> either meta and meta-example or meta-isar and 
> meta-isar-example. Currently 'meta-isar' sounds like it is required.
>   - Clearly defined task pipeline for all recipe types
>     - no more do_build with stuff in it, that should be treated a the 
> default target not some real one
>     - dpkg_runbuild should be a task with postfunc and prefunc 
> attributes to wrap mounts around it
>   - Cleanup meta-isar layer to show best practices of using isar
>     - multiconfig should not contain other variables than DISTRO and 
> MACHINE
> 
> I am sure I will find a lot more of those if I think a bit harder about 
> it. All of those issues makes adopting Isar for new, OE or Debian people 
> alike very difficult. With the 1.0 we should try to bring Isar to a 
> level were we don't expect many breaking changes on the next 1.1 release.
> 
>> At the moment I'm busy with testing/applying pending patches, I plan 
>> to finish this activity in a couple of days and make a first release 
>> candidate and code freeze (only bug fixes will be applied in the 
>> 'next') after that.
> 
> Shouldn't we open a release staging branch for that, so that feature 
> submissions can continue to next?

Does it makes sense for now with the release cycle taking one week?

Thanks,
Maxim.



> 
> Cheers,
> Claudius
> 
>> I'll submit later Changelog describing major changes since the last 
>> release and sort out the issues present on the project's wiki.
>>
>> Please inform me about any open issues that may be a subject to 
>> postpone a release.
> 
> 
> 


-- 
Maxim Osipov
ilbers GmbH
Maria-Merian-Str. 8
85521 Ottobrunn
Germany
+49 (151) 6517 6917
mosipov@ilbers.de
http://ilbers.de/
Commercial register Munich, HRB 214197
General Manager: Baurzhan Ismagulov